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COOPERATION  OF  MUTUALLY  SUSPICIOUS  SUBSYSTEMS 
IN  A  COMPUTER  UTILITY* 


by 

Michael  D.  Schroeder 


ABSTRACT 


This  thesis  describes  practical  protection  mechanisms  that 
allow  mutually  suspicious  subsystems  to  cooperate  in  a  sin¬ 
gle  computation  and  still  oe  protected  from  one  another. 

The  mechanisms  are  based  on  the  division  of  a  computation 
into  independent  domains  of  access  privilege,  each  of  which 
may  encapsulate  a  protected  subsystem.  The  central  com¬ 
ponent  of  the  mechanisms  is  a  hardware  processor  that  auto¬ 
matically  enforces  the  access  constraints  associated  with 
a  multidomain  computation  implemented  as  a  single  execution 
point  in  a  segmented  virtual  memory.  This  processor  allows 
a  standard  interprocedure  call  with  arguments  to  change  the 
domain  of  execution  of  the  computation.  Arguments  are  auto¬ 
matically  communicated  on  cross-domain  calls  —  even  between 
domains  that  normally  have  no  access  capabilities  in  common. 
The  processor,  when  supported  by  a  suitable  software  system 
which  is  also  discussed,  provides  the  protection  basis  for 
a  computer  utiJ ity  in  which  users  may  encapsulate  indepen¬ 
dently  compiled  programs  and  associated  data  bases  as  pro¬ 
tected  subsystems,  and  then,  without  compromising  the  pro¬ 
tection  of  the  individual  subsystems,  combine  protected 
subsystems  of  different  users  to  perform  various  computations. 


This  report  reproduces  a  thesis  of  the  same  title  submitted  to 
the  Department  of  Electrical  Engineering,  Massachusetts  Institute 
of  Technology,  on  September  20,  1972  in  partial  fulfillment  of 
the  requirements  for  the  Degree  of  Doctor  of  Philosophy. 


3 


i 

f 


3 

< 

< 

l 


1 


3 

j 

3 


TABLE  OF  CONTENTS 


ACKNOWLEDGEMENTS 


ABSTRACT 


LIST  OF  FIGURES 


Chapter 


1.  INTRODUCTION 


Different  Access  for  Different  Situations. 

Cooperating,  Mutually  Suspicious  Subsystems 

Objectives 

Background 

Approach 

Thesis  Plan 

Related  Work 

2.  STATIC  ACCESS,  DYNAMIC  ACCESS,  AND  CROSS-DOMAIN  CALLS 

The  Segmented  Virtual  Memory 
Multiple  Domains 
Lomain  of  Execution 
An  Exair'le  of  Mode  Arrays 
t  vcss-Domair.  Calls 
Static  Access  and  Dynamic  Access 
Dyi  ic  Access  Capabilities 
Matching  References  to  Capabilities 
Creation  of  a  New  Activation  Record 

Sunmary 

3.  THE  PROCESSOR  DESIGN 

The  Virtual  Memory  and  Static  Access  Capabilities 

Generating  Virtual  Memory  Addresses 

Call  and  Return 

Cross-Domain  Call  and  Return 

Dynamic  Access  Capabilities 

Propagation  of  Tags 

Multibit  Tags 

Pointers  as  Arguments 

The  Escape  Hatch 

Processor  Response  to  Exceptional  Conditions 


BL 

I 


Chapter 


3.  Continued 


aura— 


5 


K 

c 

F 


An  Associative  Memory  for  Dynamic  Access  Capabilities  118 
Entry  and  Label  Variables  123 
Bit  Addressing  132 
Summary  133 

4.  SGME  COMMENTS  ON  THE  SUPPORTING  SOFTWARE  136 


A  Distributed  Supervisor 
The  File  System 
Protected  Subsystems 
Permission  Flags  for  Segments 
Controlling  the  Gate  Attribute 
Examples  of  Access  Control  Lists 
Other  Issues 
Sunmary 


137 

138 

143 

144 

148 

149 
152 
154 


? 

} 

} 

a. 

1 

I 

i 

i 

i 


si 


5.  CONCLUSIONS 


155 


■m 


Areas  for  Further  Research 
BIBLIOGRAPHY 
BIOGRAPHICAL  NOTE 


160 

163 

166 


a 


LIST  OF  FIGURES 


Figure  Page 

2- 1:  Example  access  mode  arrays  for  three  domains  of  a  proce':.  43 

3- 1:  The  descriptor  segment  and  related  registers.  58 

3-2:  Pegister  and  storage  formats  for  address  formation.  64 

3-3:  ■■  'oritl.-n  for  effective  pointer  generation.  6S 

3-4:  ";at  <.  the  eigument  list  fo;  an  interprocedure  call.  70 

3-5:  C<  vie  tec:  a-\:»wvi..r.  .  ist  fort  at  for  an  interprocedure  call.  78 

3-6:  A  dynamic  a-  •  1  stack  frame  for  a  single  cross-domain  call.  80 

3-7:  Two  consecutive  cross-domain  calls  vith  one  argument  94 


casca-!  *  through  both. 

3-8:  Dynamic  access  stack  containing  frames  for  three  unreturned  99 


cross-domain  calls. 

3- 9:  Modified  algorithm  for  effective  pointer  generation  with  100 

a  multibit  tag. 

3-10:  l-*orn  At  of  a  dynamic  access  capability  giving  read  and/or  103 

write  access  to  a  subsegment. 

3-11:  Algorithm  of  the  SPPti  instruction.  109 

3-12:  Three  cases  of  the  SPPii  instruction.  110 

3-13:  Format  of  the  associative  memory  for  dynamic  access  1.9 

capabilities . 

3-14:  Specification  of  a  single  entry  variable  as  an  input  126 

argument. 

4- 1:  A  representative  directory  hierarchy.  140 

4-2:  Use  of  the  directory  hierarchy  to  organize  information  141 

stored  on-line. 

4-3:  Initial  state  of  the  domain  table  for  a  process.  145 


6 


CHAPTER  1 
INTRODUCTION 


When  considered  in  conjunction  with  computer  systems,  privacy  and 
protection  are  easily  confused.  Privacy  is  a  social  and  legal  issue. 
Privacy  means  that  the  dissemination  of  information  of  or  about  a  person 
or  group  is  controlled  by  that  person  or  group.  New  emphasis  has  been 
placed  on  guaranteeing  rights  of  privacy  in  the  face  of  the  increased 
ability  provided  by  large,  sophisticated  computer-based  information 
systems  to  gather,  catalogue,  and  analyze  data.  Protection,  on  the 
other  hand,  is  a  technical  and  economic  issue.  Protection  means  the 
mechanisms  for  specifying  and  enforcing  control.  Guaranteeing  rights 
of  privacy  requires  protection  mechanisms,  but  many  other  issues  are 
involved  as  well.  Protection  is  a  means  and  privacy  an  end. 

In  this  thesis  interest  is  centered  on  protection  mechanisms  within 
computer  systems.  The  viewpoint  is  that  of  a  computer  system  designer 
who  is  intent  upon  providing  efficient  protection  mechanisms  applicable 
to  a  wide  range  of  problems.  Questions  of  privacy  influence  this  effort 
co  the  extent  of  implying  criteria  which  must  be  met  before  such  a 
computer  system  can  be  applied  to  those  problems  where  privacy  is  an 
issue.  The  thesis,  however,  contains  little  explicit  consideration  of 
privacy. 

To  further  define  the  scope  of  the  thesis,  consideration  is  limited 
to  problems  of  hardware  and  software  organization.  While  it  is  recog¬ 
nized  that  issues  such  as  Installation  security,  communication  line 
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security,  hardware  reliability,  and  correctness  of  hardware  and  software 
implementations  of  algorithms  must  be  considered  in  order  to  achieve  the 
secure  environment  required  for  useful  application  of  protection 
mechanisms,  these  topics  are  beyond  the  scope  of  the  thesis. 

Protection  mechanisms  are  defined  to  be  those  components  of  a 
computer  system  that  control  access  of  executing  programs  to  objects  in¬ 
side  the  system.  This  definition  recognizes  that  executing  programs 
carry  out  inside  the  system  the  intentions  of  the  people  outside  the 
system.  Thus,  executing  programs  are  the  active  agents  that  must  be 
controlled  in  a  computer  system.  Hie  definition  admits  a  large  variety 
of  mechanisms,  ranging  from  write-permit  rings  on  magnetic  tape  reels 
to  sophisticated  memory  protection  hardware  and  including  access  con¬ 
trols  implemented  in  software. 

All  such  protection  mechanisms  are  directed  toward  two  overall 
objectives.  The  first  can  be  labeled  user  self-protection.  People  are 
not  infallible.  They  frequently  make  mistakes  when  conceiving  algo¬ 
rithms,  specifying  algorithms  as  programs,  and  applying  programs  to 
particular  problems.  Protection  mechanisms  permit  a  redundant  specifi¬ 
cation  of  intention  to  be  made  and  enforced.  For  example,  the  write- 
permit  ring  mentioned  above  allows  the  intention  that  a  tape  not  be 
altered  in  a  particular  situation  to  be  enforced  on  the  basis  of  speci¬ 
fications  other  than  those  provided  by  the  executing  programs.  In  gen¬ 
eral,  enforcing  limits  on  the  objects  an  executing  program  may  access 
can  detect  certain  types  of  errors  and  prc.rent  inadvertant  damage  by 


incorrect  access. 
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The  second  objective  of  protection  mechanisms  is  control  of  user 
interaction.  This  objective  surfaces  in  computer  systems  providing 
computation  and  information  storage  services  to  more  than  one  person  or 
group.  The  multiple  users  of  a  computer  system  may  have  different  goals 
and  be  responsible  to  different  authorities.  A  diverse  community  will 
use  the  same  system  only  if  it  is  possible  for  its  members  to  be  inde¬ 
pendent  of  one  another.  On  the  other  hand,  a  great  potential  benefit  of 
a  multiple  user  computer  system  is  its  ability  to  encourage  users  to 
communicate,  cooperate,  and  build  upon  one  another's  work.  Such  inter¬ 
action  is  generally  based  on  users  sharing  stored  information.  Thus, 
total  user  separation,  while  relatively  easy  to  achieve,  negates  a 
potential  benefit.  Required  to  achieve  this  benefit  is  controlled  user 
interaction.  Controlling  the  ability  of  executing  programs  to  access 
objects  in  the  system  is  the  internal  manifestation  of  controlling  user 
interaction. 

While  important  in  any  system  serving  multiple  users,  the  objec¬ 
tive  of  controlling  user  interaction  is  a  key  p~rt  of  the  service  objec¬ 
tives  defining  a  computer  utility.  In  the  remainder  of  this  thesis, 
protection  mechanisms  are  considered  in  the  context  of  a  large,  general- 
purpose,  interactive,  multiplexed  computer  system  functioning  as  a 
computer  utility.  This  context  provides  a  severe  test  of  protection 
mechanisms,  and  at  the  same  time  offers  a  large  reward  for  devising 
economic,  natural  protection  mechanisms  that  can  guarantee  total  user 
separation  when  desired,  permit  unrestricted  user  cooperation  when 
desired,  and  provide  many  intermediate  degrees  of  control. 
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Different  Access  for  Different  Situations 

The  essential  observation  underlying  all  protection  mechanisms  is 
that  executing  programs  need  different  a.:ess  in  different  situations. 

For  instance: 

-  The  programs  in  different  computations  need  different  access. 

In  a  computer  utility  serving  a  university  community,  for 
example,  programs  executing  in  a  computation  directed  by  the 
registrar  to  manipulate  academic  records  need  different  access 
to  stored  data  than  programs  executing  in  a  computation  directed 
by  a  system  administrator  to  generate  monthly  bills  for  computer 
usage. 

-  The  same  programs  in  different  computations  need  different 
access.  In  the  previous  example,  both  computations  may  share 
the  use  of  a  program  for  manipulating  hash-coded  index  tables. 

-  Different  programs  in  “he  same  computation  need  different  access. 
A  user-defined  program  executing  in  some  computation  may  invoke 

a  supervisor  program  to  initiate  I/O  channel  operation.  Presum¬ 
ably,  the  executing  supervisor  program  has  access  to  channel 
assignment  data  and  to  the  start  I/O  instruction  of  the 
processor  —  access  denied  the  executing  user  program.  Yst  both 
executing  programs  are  logically  part  of  the  same  computation. 

-  The  same  program  in  the  same  computation  needs  different  access 
for  different  circumstances.  For  example,  a  closed  subroutine 
providing  string  comparison  functions  for  all  programs  written 
in  PL/I  needs  different  access  when  invoked  by  a  supervisor 
program  than  when  invoked  by  a  user-defined  program. 

in  general,  the  access  permission  that  should  be  associated  with  an 
executing  program  depends  upon  the  specific  circumstances  of  its  execu¬ 
tion. 

A  significant  result  of  previous  work  [7,19,20)  on  protection 
mechanisms  has  been  the  development  of  a  model  that  applies  to  situa¬ 
tions  where  the  access  of  executing  programs  needs  to  differ.  This 
model  is  based  on  the  concept  of  domains  which  are  sets  of  access 
capabilities.  The  access  of  an  executing  program  depends  upon  the 
domain  of  execution  in  which  the  program  finds  itself.  An  attempt  by 
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by  an  executing  program  to  access  something  in  the  system  will  succeed 
only  if  a  capability  allowing  that  access  is  an  element  of  the  domain 
of  execution.  (Ways  of  defining  the  capabilities  in  domains  and  of 
determining  the  domain  of  execution  at  any  given  time  will  be  discussed 
lacer. ) 

There  is  practically  no  limit  to  the  types  of  capabilities  that  can 
be  defined.  A  capability  is  simply  an  ordered  pair  specifying  the  name 
of  something  in  the  system  and  the  operations  which  can  be  performed  on 
that  object.  Thus,  there  can  be  capabilities  to  allow  any  well-defined 
operation  on  any  named  object  in  a  system.  Capabilities  to  read  and 
write  data  items  and  to  execute  programs  are  obvious  examples.  Capa¬ 
bilities  to  do  I/O  over  a  specific  channel,  to  add  capabilities  to 
domains,  and  to  change  the  domain  of  execution  to  a  particular  domain 
are  less  obvious  examples.  The  different  types  of  capabilities  present 
depend  upon  the  particular  system  being  considered. 

The  domain  model  provides  a  conceptual  framework  in  which  to  con¬ 
sider  the  protection  mechanisms  of  any  system.  For  instance,  the  model 
is  easily  related  to  the  examples  given  previously.  By  using  a  distinct 
domain  of  execution  for  each  computation  in  a  system,  executing  programs 
automatically  assume  the  access  capabilities  associated  with  the  com¬ 
putation  of  which  they  are  part,  as  required  in  the  first  and  second 
examples.  By  alternately  using  two  domains  of  execution  for  a  single 
computation,  the  supervisor /user  distinction  of  the  third  and  fourth 
examples  can  be  dealt  with.  Multiple  domains  per  computation  can  deal 
with  more  complex  situations  as  well. 


One  of  the  most  complex  instances  of  multiple  domains  in  a  single 
computation  is  the  case  of  mutually  suspicious  subsystems  cooperating 
in  the  same  computation.  This  case  provides  a  good  test  of  a  set  of 
protection  mechanisms.  Since  protection  mechanisms  that  can  deal  with 
cooperating,  mutually  suspicious  subsystems  are  the  central  concern  of 
this  thesis,  further  discussion  of  this  case  is  appropriate. 

An  essential  idea  underlying  the  case  of  cooperating,  mutually 
suspicious  subsystems  is  that  of  a  protected  subsystem.  A  protected 
subsystem  is  a  collection  of  programs  and  data  bases  that  is  encapsula¬ 
ted  so  that  other  executing  programs  can  invoke  certain  component 
program^  within  tne  protected  subsystem,  but  are  prevented  from  reading 
or  writing  component  programs  and  data  bases,  and  are  prevented  from 
disrupting  the  intended  operation  of  the  component  programs.  The 
supervisor  of  most  computer  systems  is  a  good  example  of  a  protected 
subsystem.  A  few  systems  (notably  the  CAL  system  [15,18,26,27]  and 
Multics  [5,21,23])  allow  normal  users  to  define  their  own  protected 
subsystems  and,  with  certain  restrictions,  make  them  available  to  be 
invoked  by  the  programs  of  other  users. 

Protected  subsystems  are  useful  for  implementing  complex  controls 
on  access  to  data  bases  and  for  maintaining  the  secrecy  of  proprietary 
algorithms  which  are  shared.  In  the  first  case  the  programs  of  a  pro¬ 
tected  subsystem  act  as  caretakers  for  the  contained  data  bases  and 
interpret ively  enforce  arbitrarily  complex  controls  on  access  to  them. 
Programs  outside  the  protected  subsystem  are  allowed  to  access  the  con¬ 
tained  data  bases  only  by  invoking  the  caretaker  programs.  The 


algorithms  manifest  in  these  programs  may  judge  the  propriety  of  the 
requested  access  based  on  information  provided  by  the  system  on  the 
identity  of  the  invoking  program  and  the  circumstances  of  invocation. 

The  caretaker  programs  may  even  record  each  access  request  in  one  of 
the  encapsulated  data  bases.  No  action  by  an  outside  program  can  dis¬ 
rupt  the  operation  of  the  caretaker  programs  in  judging,  performing,  or 
recording  requested  accesses. 

In  the  case  of  maintaining  the  secrecy  of  shared,  proprietary 
algorithms,  the  programs  in  a  protected  subsystem  may  be  invoked  by 
outside  programs  but  not  read  by  them.  In  addition,  none  of  the  tempo¬ 
rary  or  permanent  data  associated  with  the  programs  in  the  protected 
subsystem  may  be  read  or  written  by  outside  programs.  Thus,  the  pro¬ 
grams  in  the  protected  subsystem  may  be  used  by  other  programs,  but  no 
aspect  of  their  structure  examined. 

So  far  the  properties  of  a  protected  subsystem  have  been  developed 
from  the  point  of  view  of  a  program  outside  invoking  a  program  inside. 

It  is  also  conceivable  that  in  the  course  of  its  operation  a  program 
inside  a  protected  subsystem  might  need  to  invoke  a  program  outside. 

This  reverse  operation  is  useful  only  if  it  does  not  compromise  che 
prot&ctsd  subsystem. 

A  case  of  cooperating,  mutually  suspicious  subsystems  arises  when 
two  or  more  protected  subsystems  are  involved  in  the  same  computation. 

An  example  of  this  situation  occurs  if  a  program  inside  a  protected  sub¬ 
system  invokes  a  program  outside  that  happens  to  be  inside  another  pro¬ 
tected  subsystem.  An  example  involving  a  less  direct  form  of  cooperation 
arises  if  programs  in  two  different  protected  subsystems  are  alternately 
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invoked  by  programs  outside  both.  Arbitrary  structures  involving  any 
number  of  protected  subsystems  can  be  imagined. 

The  domain  model  deals  naturally  with  the  notion  of  protected  sub¬ 
systems.  Each  encapsulation  is  just  a  different  domain  containing 
capabilities  to  execute  the  component  programs  and  read  or  write  the 
component  data  bases.  The  case  of  mutually  suspicious  subsystems  co¬ 
operating  in  a  single  computation  corresponds  to  a  multidomain  computa¬ 
tion  in  which  the  domains  involved  have  few  access  capabilities  in 
common. 

A  computer  utility  which  allows  user-defined  protected  subsystems 
to  cooperate  in  computations  could  be  put  to  good  use.  For  example, 
imagine  that  a  consulting  firm  has  developed  and  calibrated  a  demand 
model  for  interzoual  traffic  flow  in  a  large  metropolitan  area. 

Model  development,  data  gathering,  and  model  calibration  were  done  at 
great  expense,  and  the  firm  wishes  to  sell  the  use  of  its  model  in  order 
to  profit  from  the  investment.  To  this  end  the  model  is  implemented  in 
a  computer  utility.  The  resulting  subsystem  includes  a  set  of  programs 
which  embody  the  prediction  algorithms,  and  several  data  bases  contain¬ 
ing  socio-economic  parameters  and  door-to-door  survey  results.  In  order 
to  vend  this  subsystem  to  other  users  of  the  computer  utility,  the  con¬ 
sulting  firm  encapsulates  it  as  a  protected  subsystem. 

Now  imagine  that  a  planning  board  for  the  area  is  studying  express¬ 
way  networks  to  meet  future  transportation  needs.  As  part  of  this  task 
they  have  constructed  a  model  which  calculates  level-of-service  param¬ 
eters  for  an  expressway  network,  given  the  physical  attributes  and  the 
traffic  volume.  This  model,  along  with  a  wealth  of  related  data,  is 
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also  represented  as  a  protected  subsystem  in  the  computer  utility.  For 
one  aspect  of  their  study  the  planning  board  will  perform  a  series  of 
network  equilibrium  flow  analyses  for  various  expressway  configurations. 
In  these  calculations  the  planning  board  will  use  the  demand  model 
vended  by  the  consulting  firm. 

The  resulting  computation  is  a  case  of  cooperating,  mutually  suspi¬ 
cious  subsystems.  The  consulting  firm  wishes  to  avoid  divulging  their 
expensively  gathered  data  and  expensively  devised  algorithms,  and  wishes 
to  make  secure  records  of  use  for  later  billing.  The  planning  board 
wishes  to  avoid  premature,  uncensored  release  of  the  various  routing 
and  cost  information  for  potential  expressway  configurations  that  is 
accessible  to  their  programs  for  this  and  other  phases  of  the  study. 

The  encapsulation  of  the  consulting  firm's  demand  model  as  a  pro¬ 
tected  subsystem  guards  their  proprietary  interests.  Access  by  the 
planning  board  subsystem  is  restricted  to  invoking  a  few  carefully 
selected  programs.  The  planning  board  subsystem  cannot  read  the  code 
or  the  data  bases  of  the  demand  model,  nor  subvert  its  operation  in  any 
way.  The  consulting  firm  subsystem  can  make  protected  usage  records  as 
it  operates  from  which  bills  can  be  generated  later. 

Likewise,  the  encapsulation  of  the  planning  board  programs  and 
data  bases  protects  the  interests  of  the  planning  board.  The  consult¬ 
ing  firm  subsystem  cannot  read  or  alter  the  sensitive  data  that  is 
accessible  to  the  planning  board  programs.  The  consulting  firm  sub¬ 
system  just  has  temporary  access  to  whatever  input  parameters  the  plan¬ 
ning  board  subsystem  provides  each  time  that  it  invokes  the  demand 


<3 

U 

3 


as 


t1 


ii  'i*  jin  11  iH  -i&xM  14  *  Ukiuuu*  l*  .  O-U* 


model.  Also,  the  only  way  that  the  consulting  firm  subsystem  can  in¬ 
fluence  the  operation  of  the  planning  board  subsystem  is  with  the  values 
of  the  answers  calculated  by  the  former  for  the  latter. 

This  simple  example  involving  two  protected  subsystems  is  represen¬ 
tative  of  a  large  class  of  potential  applications  for  a  computer  utility 
that  supports  cooperating,  mutually  suspicious  subsystems.  Such , a 
facility  would  permit,  among  other  things,  the  packaging  of  knowledge  in 
an  active  form  as  program  complexes  and  the  marketing  of  this  knowledge 
in  a  way  that  preserves  the  proprietary  interests  of  the  seller  and 
limits  the  possibility  of  harm  to  the  customers.  Of  course,  this 
facility  cannot  guarantee  that  a  marketed  program  complex  correctly  per¬ 
forms  the  functions  that  it  is  advertised  to  perform.  Issues  of  program 
certification  are  beyond  the  scope  of  this  thesis.  The  important  point 
is  that,  even  if  a  program  malfunctions  or  behaves  maliciously,  the  use 
of  protected  subsystems  limits  the  resulting  damage. 

A  computer  utility  that  supports  cooperating,  mutually  suspicious 
subsystems  would  favorably  impact  casual  programming  users  as  well  as 
those  affiliated  with  expensive  proprietary  projects  or  those  manipula¬ 
ting  sensitive  data.  An  important  activity  of  most  programming  users  in 
a  computer  utility  is  sharing  programs  and  program  complexes  with  one 
another.  The  access  environment  in  which  the  programs  of  such  a  user 


In  some  cases  it  may  be  desirable  to  guarantee  that  a  protected  sub¬ 
system  invoked  by  another  cannot  remember  and  later  divulge  the  values 
of  input  parameters.  This  problem  appears  to  be  very  difficult  to  solve 
in  a  purely  technical  way  and  will  not  be  considered  in  this  thesis.  A 
practical  solution  probably  involves  program  certification  and  means  for 
legal  redress  in  cases  of  unauthorized  release  of  such  information. 
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normally  execute  on  his  behalf  could  be  set  up  as  a  protected  subsystem. 
Then  the  user  could  arrange  for  programs  borrowed  from  other  users  to 
execute  outside  of  this  "home”  protected  subsystem.  In  this  manner  the 
borrowed  programs  could  be  invoked  without  giving  them  access  to  all  the 
programs  and  data  of  the  borrower.  If  the  borrowed  program  is  malicious, 
or  malfunctions,  the  damage  it  can  do  is  thereby  limited.  The  lending 
user  also  would  have  the  option  to  encapsulate  the  lent  program  or 
program  complex  in  a  protected  subsystem  of  its  own  and  thus  insulate 
it  from  the  programs  of  the  borrower.  The  result  of  this  pattern  is  an 
environment  in  which  casual  sharing  of  programs  is  encouraged  by  the 
ability  to  limit  the  potential  damage  to  the  participating  users. 


Objectives 

The  objective  of  the  research  reported  here  is  to  devise  protection 
mechanisms  that  allow  cooperating,  mutually  suspicious  subsystems  to  be 
implemented  efficiently  and  naturally  in  a  computer  utility.  As  has 
been  suggested,  this  case  corresponds  to  a  multidomain  computation  in 
which  the  domains  have  few  capabilities  in  common.  The  essential 
difficulty  is  that  common  capabilities  seam  to  be  a  prerequisite  to 
cooperation  and  communication  among  subsystems  encapsulated  in  differ¬ 
ent  domains.  Thus,  in  this  respect,  cooperating,  mutually  suspicious 
subsystems  is  a  "worst  case"  problem.  Means  must  be  provided  for  pro¬ 
grams  executing  in  different  domains  to  communicate  even  when  these 
domains  normally  have  no  capabilities  in  common.  The  mechanisms 
developed  in  this  thesis,  however,  do  not  force  the  sets  of  capabilities 
that  are  the  domains  in  a  computation  to  be  disjoint.  There  are  no 
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arbitrary  restriction:;  on  the  capabilities  that  can  be  included  in  the 
domains  As  a  result,  these  protection  mechanisms  are  able  to  enforce 
as  well  a  large  variety  of  protection  relationships  that  are  less  re¬ 
strictive  than  those  associated  with  cooperating,  mutually  suspicious 
subsystems. 

The  words  ''eff iciently"  and  "naturally,,  are  used  to  convey  the  aim 
of  developing  practical  mechanisms  which  meet  the  functional  objective  — 
mechanisms  that  people  actually  might  build  and  use.  This  requirement 
is  manifest  in  three  specific  design  criteria:  economy,  simplicity, 
and  programming  generality.  Economy,  obviously  related  to  efficiency, 
encompasses  two  considerations.  First,  the  cost  of  building  the  pro¬ 
tection  mechanisms  should  be  small  enough  relative  tc  the  cost  of  the 
entire  system  that  the  system  designers  are  willing  to  include  such 
mechanisms  in  the  system  despite  an  untested  market.  Second,  the  cost 
of  using  the  mechanisms  should  be  low  enough  that  it  is  not  an  important 
consideration  in  determining  the  degree  of  access  control  to  be  used  in 
a  particular  application.  Cost  in  the  first  case  is  the  per  system 
fixed  cost  of  providing  the  protection  mechanisms.  Cost  in  the  second 
case  is  the  marginal  cost  of  application,  and  includes  the  subsystem 
complexity  and  user  inconvenience  that  result  from  the  use  of  the 
mechanisms,  as  well  as  any  associated  extra  storage  space  and  execution 
time. 

Simplicity  often  leads  to  economy,  but  is  identified  as  a  separate 
criterion  for  a  more  important  reason.  If  a  set  of  protection 
mechanisms  is  to  be  accepted  and  used,  then  there  must  be  confidence 
that  no  way  exists  to  circumvent  it.  The  best  way  to  achieve  confidence 
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is  to  keep  the  mechanisms  simple  so  that  they  may  be  completely  under¬ 
stood.  In  this  respect  standard  techniques  for  controlling  complexity, 
such  as  functional  modularity  and  adherence  to  a  few  overall  design 
principles,  can  help. 

Programming  generality,  the  third  criterion,  is  adopted  as "the 
specific  manifestation  of  naturalness.  First  defined  by  Dennis  [8,9,10], 
it  is  a  property  that  has  proven  the  key  to  encouraging  users  of  a  com¬ 
puter  utility  to  communicate,  cooperate,  and  build  upon  one  another's 
work.  As  used  here,  it  means  that  independent  programs  may  be  combined 
in  various  ways  iuto  larger  units  without  understanding  or  altering  the 
internal  organizations  of  the  programs.  The  idea  is  that  independently 
written  and  compiled  programs  of  one  o'  more  computer  utility  users  can 
be  used  as  building  blucks  which  can  be  combined  in  various  ways  into 
different  program  complexes  to  perform  different  computations.  In  the 
course  of  such  activity  a  single  program  or  program  complex  may  have  to 
operate  in  many  different  pr  >tection  environments.  If  the  protection 
mechanisms  of  a  computer  utility  are  to  be  consistent  with  the  criterion 
of  programming  generality,  then,  it  must  be  possible  to  change  the 
protection  environment  of  a  program  or  group  of  programs  without 
altering  the  internal  structure  of  the  program  or  group, 

Hie  programming  generality  criterion  generates  some  specific  func¬ 
tional  requirements  for  the  protection  mechanisms  of  this  thesis.  These 
requirements  are  now  developed  into  a  more  precise  statement  of  the 
thesis  objective.  The  initial  assumption  is  that  a  call  with  arguments 
is  an  accepted  method  of  communication  between  independent  programs  and 
should  be  supported  in  any  general  purpose  computer  system  such  as  a 
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computer  utility.  In  keeping  with  the  criterion  of  programming  general¬ 
ity,  many  systems  allow  separately  compiled,  independent  programs  to 
communicate  via  a  call  that  passes  arguments.  The  only  requirements  for 
such  communication  are  that  the  programs  involved  use  the  same  calling 
conventions  and  that  they  agree  on  the  number,  kind,  and  order  of  the 
arguments.  No  explicit  knowledge  of  the  circumstances  of  execution  need 
be  embedded  in  the  calling  or  the  called  program.  A  single  call  state¬ 
ment  in  some  program  can  invoke  many  different  programs  depending  upon 
the  circumstances  at  the  time  the  compiled  version  of  the  statement  is 
executed. 

It  seems  reasonable  that  the  domain  in  which  a  program  will  execute 
when  called  not  be  part  of  the  knowledge  requited  in  order  to  write  or 
compile  programs  that  invoke  it.  A  natural  consequence  of  this  view  is 
that  the  standard  call  used  between  independent  programs  should  auto¬ 
matically  change  the  domain  of  execution  if,  in  a  given  circumstance, 
the  called  program  is  supposed  to  execute  in  a  different  domain  than  the 
current  domain  of  execution.  The  programmer  or  the  compiler  cannot  do 
anything  special  for  calls  that  cause  the  domain  of  execution  to  change 
(as  opposed  to  calls  that  leave  the  domain  of  execution  unchanged)  be¬ 
cause  programming  generality  requires  that  such  calls  not  be  differen¬ 
tiated  when  a  program  is  written  or  compiled. 

The  passing  of  arguments  with  a  call  needs  further  consideration 
in  light  of  the  requirement  that  a  standard  call  between  independent 
programs  can  change  the  domain  of  execution  if  necessary.  An  argument 
may  be  any  data  item  or  set  of  data  items  that  the  calling  program  can 
specify.  There  are  rwo  fundamental  methods  that  can  be  used  to  pass 
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arguments  with  a  call.  One  is  to  copy  the  values  of  the  arguments  into 
memory  locations  or  registers  where  the  called  program  expects  to  find 
them.  The  second  is  to  leave  most  arguments  in  their  normal  memory 
locations  and  ir. 'arm  the  called  program  of  the  addresses  of  the  argu¬ 
ments.  The  criterion  of  economy  makes  it  imperative  to  support  the 
second  method.  The  copying  involved  in  the  first  method  would  be  so 
expensive  that  the  passing  of  large  arguments  (arrays,  structures,  etc.) 
would  be  discouraged.  Further,  the  functional  effect  of  passing  argu¬ 
ments  by  value  can  be  achieved  when  required  with  a  mechanism  based  on 
passing  arguments  by  address.  The  reverse  is  not  true,  for  modification 
of  an  argument  passed  by  value  immediately  changes  only  a  copy  of  the 
source  variable,  not  the  source  variable  itself.  More  sophisticated 
linguistic  constructions  for  passing  arguments,  such  as  passing  them  by 
name,  also  can  be  implemented  based  on  mechamisms  that  pass  arguments 
by  address. 

Passing  arguments  by  address,  however,  can  generate  problems  in  the 
case  of  calls  that  happen  to  change  the  domain  of  execution.  For  such 
arguments  to  be  referenced  by  the  called  program,  the  domain  of  execu¬ 
tion  of  the  called  program  must  contain  capabilities  which  allow  access 
to  the  memory  locations  containing  the  arguments.  The  domain  of  the 
calling  program  and  the  domain  of  the  called  program  essentially  are 
required  to  have  capabilities  ir.  common  permitting  the  arguments  to  be 
' aferenced. 

There  are  several  ways  that  this  need  for  common  argument  capabili¬ 
ties  conceivably  could  be  met.  One  approach  is  to  allow  cross-domain 
calls  only  if  the  capabilities  in  the  celling  domain  form  a  subset  of 
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arguments  with  a  call.  One  is  to  copy  the  values  of  the  arguments  into 
memory  locations  or  registers  where  the  called  program  expects  to  find 
them.  The  second  is  to  leave  most  argumencs  in  their  normal  memory 
locations  and  inform  the  called  program  of  the  addresses  of  the  argu¬ 
ments.  The  criterion  of  economy  makes  it  imperative  to  support  the 
second  method.  The  copying  involved  in  the  first  method  would  be  so 
expensive  that  the  passing  of  large  arguments  (arrays,  structures,  etc.) 
would  be  discouraged  Further,  the  functional  effact  of  passing  argu¬ 
ments  by  value  can  be  achieved  when  required  with  a  mechanism  based  on 
passing  arguments  by  address.  The  reverse  is  not  true,  for  modification 
of  an  argument  passed  by  value  immediately  changes  only  a  copy  of  the 
source  variable,  not  the  source  variable  itself.  More  sophisticated 
linguistic  constructions  for  passing  arguments,  such  as  passing  them  by 
name,  also  can  be  implemented  based  on  mechamisms  that  pass  arguments 
by  address. 

Passing  arguments  by  address,  however,  can  generate  problems  in  the 
case  of  calls  that  happen  to  change  the  domain  of  execution.  For  such 
arguments  to  be  referenced  by  the  called  program,  the  domain  of  execu¬ 
tion  of  the  called  program  must  contain  capabilities  which  allow  access 
to  the  memory  locations  containing  the  arguments.  The  domain  of  the 
calling  program  and  the  domain  of  the  called  program  essentially  are 
required  to  have  capabilities  in  common  permitting  the  arguments  to  be 
referenced. 

There  are  several  ways  that  this  need  for  common  argument  capabili¬ 
ties  conceivably  could  be  met.  One  approach  is  to  allow  cross-domain 
calls  only  ■£  the  capabilities  in  the  calling  domain  form  a  subset  of 


the  capabilities  in  the  called  domain.  Thus,  any  argument  that  the 
calling  program  happens  to  pass  is  accessible  to  the  called  program. 

If  one  domain  is  a  subset  of  another,  however,  then  the  two  domains 
certainly  cannot  encapsulate  mutually  suspicious  subsystems.  Thus, 
mechanisms  based  on  this  approach  do  not  allow  direct  cooperation  be¬ 
tween  mutually  suspicious  subsystems  by  a  call  from  one  to  the  other. 

Another  possibility  is  the  a  priori  inclusion  in  a  domain  of  the 
precise  capabilities  required  to  reference  all  arguments  that  will  be 
passed  with  all  possible  incoming  cross-domain  calls.  This  method  is 
not  practical,  however,  because  the  binding  of  variable  names  to  memory 
locations  can  vary  dynamically  as  programs  execute.  This  dynamic  bind¬ 
ing  makes  it  impossible  to  include  in  advance  the  proper  capabilities  in 
the  called  domain.  Even  if  this  problem  could  be  solved,  a  priori 
inclusion  of  capabilities  for  arguments  would  violate  the  criterion  of 
programming  generality  as  it  applies  to  domains  by  requiring  detailed 
knowledge  of  programs  making  incoming  cross-domain  calls  in  order  to 
define  a  domain. 

A  third  possibility  is  the  establishment  by  mutual  agreement  be¬ 
tween  a  domain  and  each  potential  calling  domain  of  a  special  buffer  for 
transmitting  arguments.  Capabilities  to  reference  the  buffer  would  be 
concnon  to  the  domains.  The  use  of  a  buffer  for  arguments  on  all  calls, 
whether  they  change  the  domain  of  execution  or  not,  really  means  that 
arguments  are  passed  by  value,  a  technique  Jscarded  eorlier  as 
uneconomical.  The  use  of  a  buffer  only  for  cross-domain  calls  compro¬ 
mises  program  generality. 


i 

3 


£ 

3 

a 

3 

I 


3 


24 


proposed  here  extend  the  idea  so  that  protected  subsystems  may  be  used 
as  building  blocks  as  well.  Independently  defined  protected  subsystems 
may  be  combined  in  different  ways  as  cooperative  partners  in  various 
computations  without  either  explicitly  modifying  the  definitions  of  the 
protected  subsystems  or  altering  the  component  programs. 

Background 

The  protection  mechanisms  developed  in  this  thesis  are  strongly 
influenced  by  the  structure  of  Multics.  Multics  is  a  prototype  computer 
utility  developed  at  M.I.T.'s  Project  MAC  in  a  joint  effort  with  Honey¬ 
well  Information  Systems,  Inc.  and  now  operating  at  several  sites.  (See 
[5,21,23]  for  an  introduction  to  Multics.)  No  claim  is  made  chat 
Multics  provides  the  best  possible  environment  in  which  to  develop 
practical  protection  mechanisms  which  meet  the  stated  objectives. 

Multics  is  used  because  it  is  the  closest  operational  approximation  to 
a  computer  utility  currently  existing  and  because  it  is  structured  to 
allow  programs  to  be  used  as  building  blocks  in  the  manner  discussed 
earlier  [10].  Because  Multics  is  an  operational  system  that  has  proven 
effective  in  meeting  many  of  the  objectives  of  a  computer  utility,  there 
can  be  some  confidence  that  protection  mechanisms  designed  for  a  similar 
system  environment  are  based  on  realistic  assumptions.  Protection 
mechanisms  have  a  tendency  to  permeate  a  system.  In  this  case  the 
existing  Multics  can  be  used  as  a  concrete  system  environment  in  which 
to  test  the  protection  mechanisms  by  tracing  their  full  system  implica¬ 
tions.  The  fact  that  the  protection  mechanisms  described  here  represent 
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the  evolution  and  improvement  of  an  existing,  useful  system  lends 
strength  to  the  contention  that  they  are  practical. 

The  relationship  of  the  protection  mechanisms  described  in  this 
thesis  to  Muitics  is  made  clearer  by  briefly  reviewing  certain  aspects 
of  the  system.  Muitics  already  includes  a  fairly  sophisticated  set  of 
protection  mechanisms,  particularly  for  controlling  access  to  stored 
information.  On-line  storage  is  logically  organized  as  a  collection  of 
disjoint  segments  of  information.  Segments  are  variable  length  arrays 
of  bits  that  may  contain  any  collection  of  information,  e.g.,  symbolic 
programs,  compiled  programs,  data  files,  temporary  storage  for  on-going 
computations,  or  system  date  bases.  Any  segment  is  potentially  access¬ 
ible  to  any  executing  program. 

Muitics  is  organized  so  that  separately  compiled  programs  may  be 
used  as  building  blocks.  While  this  goal  influences  the  organization  of 
the  entire  svstem,  several  features  are  particularly  important.  Com¬ 
piled  programs  are  represented  as  segments  of  pure  procedure  so  that 
multiple  computations  may  simultaneously  execute  the  same  shared  proce¬ 
dure  segment.  Interprccedure  communication  is  by  a  standardized  inter¬ 
procedure  call  and  interprocedure  linking  is  done  dynamically  the  first 
time  a  particular  call  is  executed  in  a  computation.  The  normal  execu¬ 
tion  environment  includes  a  push-down  stack  for  procedure  activation 
records,  allowing  procedures  to  be  combined  in  patterns  that  may  generate 
recursive  invocations. 

Machine  language  programs  in  Muitics  execute  in  a  segmented  virtual 
memory  where  segments  are  identified  by  number.  The  two-part  address 
(s,^)  identities  displacement  a  in  the  segment  numbered  js.  Processors  [17] 
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contain  logic  for  automatically  translating  two-part  addresses  into 
absolute  memory  addresses.  Translation  is  done  using  the  segment  number 
as  the  index  into  a  table  of  segment  descriptors  called  the  descriptor 
segment.  When  an  executing  program  wishes  to  reference  a  segment  stored 
on-line,  the  segment  must  first  be  added  to  the  virtual  memory  by 
assigning  it  an  unused  descriptor  segment  entry,  an  operation  automati¬ 
cally  performed  by  the  supervisor  when  the  first  attempt  to  reference 
the  segment  is  detected.  (See  [1]  for  a  more  detailed  description  of 
this  virtual  memory.) 

The  combination  of  an  execution  point  and  a  virtual  memory  is 
called  a  process.  A  process  with  a  new  virtual  memory  is  created  for 
each  user  when  he  logs  in  to  the  system.  Thus,  each  user's  process  has 
its  own  descriptor  segment.  In  this  context  it  is  convenient  to  use  the 
term  computation  to  .iean  the  activity  of  the  process  of  a  user. 

The  allowed  access  of  executing  programs  to  each  segment  stored 
on-line  is  specified  by  an  access  control  list.  An  access  control  list 
entry  essentially  associates  r.  domain  name  with  some  combination  of 
read,  write,  and  execute  access  to  the  segment.  A  domain  name  is  the 
combination  of  the  name  of  some  system  user  with  one  of  the  integers  0 
through  7,  and  designates  one  of  the  eight  fixed  domains  associated  with 
the  process  of  some  user.  Each  access  control  list  entry  defines  a 
capability  in  the  named  domain  that  allows  the  indicated  access  to  the 
segment.  Manipulation  of  access  control  lists  is  controlled  by  other 
access  control  lists  that  are  part  of  a  hierarchy  of  segment  catalogues. 

As  implied  in  the  previous  paragraph,  Multics  allows  multiple  do¬ 
mains  to  be  associated  with  a  single  process.  The  domain  of  execution 
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is  changed  by  the  standard  interprocedure  call.  Arguments  are  passed  by 
address.  The  problem  of  arranging  for  the  common  argument  capabilities 
between  the  calling  domain  and  the  called  domain  is  solved  by  forcing 
all  domains  associated  with  a  single  process  to  form  a  linearly  nested 
collection  of  sets  with  respect  to  segment  referencing  capabilities  [14]. 
Cross-domain  calls  are  allowed  only  if  the  called  domain  is  a  superset 
of  the  calling  domain.  This  linear  nesting  generates  a  total  ordering 
with  respect  to  access  privilege  on  the  domains  associated  with  a  process 
that  simplifies  many  aspects  of  the  system  in  addition  to  cross-domain 
calls.  As  pointed  out  earlier,  however,  this  approach  does  not  allow 
direct  cooperation  by  interprocedure  call  of  domains  encapsulating 
mutually  suspicious  subsystems.  In  fact,  it  does  not  even  allow  mutuall’* 
suspicious  subsystems  to  be  part  of  the  same  process. 

The  protection  mechanisms  described  in  this  thesis  are  similar  in 
overall  approach  to  those  in  Multics.  They  developed  from  considering 
ways  to  improve  the  efficiency  of  cross-domain  calls  for  the  case  of 
linearly  nested  domains,  and  then  considering  ways  to  remove  entirely 
the  linear  nesting  restriction.  The  result  of  the  first  phase  was  a 
previously  reported  [25]  hardware  architecture  for  automatically  handling 
cross-domain  calls  with  arguments  in  the  case  of  linearly  nested  domains. 
This  design,  implemented  in  a  new  processor  for  Multics  being  constructed 
by  Honeywell,  contains  the  seeds  of  many  ideas  that  are  expanded  as  the 
central  part  of  this  thesis  into  a  hardware  architecture  for  automati¬ 
cally  handling  the  unconstrained  case  of  cross-domain  calls  with  argu¬ 
ments.  In  addition  to  devising  hardware  that  automatically  performs 
general  cross-domain  calls,  the  second  phase  included  isolating  those 
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procedures,  to  name  a  few  examples,  are  all  represented  as  stored  infor¬ 
mation.  It  follows  that  control  of  access  to  stored  information  is  a 
basic  function  of  protection  mechanisms.  This  observation  is  reflected 
in  the  design  of  the  protection  mechanisms  developed  in  this  thesis. 

The  hardware  component  of  these  mechanisms  is  a  processor  that 
supports  a  multidomain  computation  implemented  as  a  single  MulLics-like 
process,  i.e.,  as  a  single  execution  point  in  a  segmented  virtual 
memory.  This  processor  automatically  controls  access  to  a  primitive 
set  of  information  objects  by  interpreting  and  enforcing  capabilities 
representing  both  the  encapsulations  defined  by  the  domains  of  the 
process  and  the  arguments  passed  with  cross-domain  calls.  The  encapsu¬ 
lation  capabilities  recognized  are  those  allowing  direct  read  or  write 
references  to  segments  and  those  allowing  transfers  of  the  execution 
point  from  one  virtual  memory  location  to  another  (including  trans  ^rs 
that  represent  cross-domain  calls).  The  cross-domain  argument  capabili¬ 
ties  recognized  by  the  processor  allow  most  types  of  data  items  defined 
by  current,  general-purpose,  high-level  programming  languages  to  be 
passed  as  arguments  with  cross-domain  calls.  The  processor  automatically 
adds  the  required  argument  capabilities  to  the  called  domain  when  a 
cross-domain  call  occurs  and  removes  them  when  the  subsequent  return 


occurs. 


The  hardware  processor  provides  a  general  foundation  for  a  software 
second  layer  of  the  protection  mechanisms.  To  get  off  the  ground,  one 
of  the  domains  supported  by  the  hardware  is  given  capabilities  allowing 
direct  read/write  access  to  the  segments  containing  the  capabilities 
that  the  hardware  enforces.  Thus,  the  hardware  is  circularly  applied 
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to  protect  the  stored  capabilities  that  control  it.  This  special 
domain  becomes  the  domain  encapsulating  the  most  highly  privileged  part 
of  the  supervisor.  Manipulation  of  the  capabilities  controlling  the 
hardware  by  procedures  executing  in  other  domains  can  only  be  done 
interpretively  by  calling  the  supervisor  procedures.  Part  of  the 
supervisor  is  a  file  system  that  allows  users  to  define  the  encapsula¬ 
tion  of  segments  as  protected  subsystems  and  control  the  sharing  of  such 
protected  subsystems.  Control  on  such  specification  is  enforced 
interpretively  by  the  file  system  procedures  based  on  inforiuation  stored 
in  the  file  system  data  segments.  Software  to  provide  other  supervisor 
■  functions,  such  as  multiplexing  processors  to  create  many  simultaneous 
processes,  is  also  encapsulated  in  the  supervisor  domain. 

Notice  that  the  hardware  processor  interprets  and  enforces  only 
capabilities  allowing  direct  access  by  executing  procedures  to  a  few 
simple  information  objects:  segments,  arguments,  and  domains.  This 
fairly  simple  processor,  however,  manages  to  handle  automatically  the 
vast  majority  of  accesses  to  objects  by  executing  programs,  creating  a 
relatively  efficient  system.  More  complex  information  objects  can  be 
created  and  access  to  them  enforced  by  using  the  basic  facilities  of 
this  hardware.  The  method  is  to  define  protected  subsystems  that 
encapsulate  segments  containing  the  stored  manifestations  of  these  more 
complex  objects  with  procedures  which  provide  interpretive  access  to 
them.  The  file  system,  itself  an  example  of  this  encapsulation  strategy, 
provides  the  basic  tools  allowing  users  to  perform  such  encapsulations 
for  themselves.  Examples  of  information  objects  to  be  discussed  later 
that  are  defined  and  controlled  by  the  file  system  are  access  control 
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lists,  directories,  and  protected  subsystems.  Other  information  objects 
defined  and  controlled  by  the  supervisor  domain  might  be  processes, 

I/O  streams,  and  interprocess  message  queues.  There  i.s  no  limit  to  the 
complexity  of  the  information  objects  and  associated  access  controls 
users  can  define  by  creating  their  own  protected  subsystems. 


Thesis  Plan 


The  central  material  of  this  thesis  is  the  development  of  the  hard¬ 
ware  processor.  Chapter  2  presents  the  conceptual  basis  for  the  protec¬ 
tion  mechanisms  in  the  processor.  The  properties  of  encapsulation  and 
argument  capabilities  are  derived  and  the  steps  involved  in  performing 
a  cross-domain  call  are  considered.  These  ideas  are  expanded  in  Chap¬ 
ter  3  into  a  description  of  a  processor  that  fully  supports  a  computa¬ 
tion  involving  multiple  independent  domains  and  that  automatically 
performs  cross-domain  calls  with  arguments  —  even  between  domains  that 
normally  have  no  capabilities  in  common.  Included  in  this  chapter  is 
a  discussion  of  the  machine  code  to  be  generated  by  compilers  to  take 
full  advantage  of  the  processor  protection  mechanisms  and  of  the  high- 
level  programming  language  extensions  required  to  allow  progranmers  to 
control  the  cross-domain  call  mechanisms. 

The  software  second  layer  is  considered  in  less  detail  than  the 
hardware  first  layer.  In  Chapter  4  a  file  system  is  described  by  out¬ 
lining  extensions  to  the  Multics  file  system  that  permit  it  to  deal  with 
protected  subsystems.  The  extensions  necessary  are  the  addition  of 
protected  subsystems  to  the  objects  catalogued  by  the  file  system  and 
the  recasting  of  access  control  lists  in  '  ms  of  protected  subsystem 
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names  rather  than  domain  numbers.  A  first  approximation  for  the  remain¬ 
ing  software  system  required  to  produce  a  computer  utility  in  which  seg¬ 
ments  and  protected  subsystems  can  be  used  as  building  blocks  is  obtained 
by  adopting  the  rest  of  the  Multics  software  organization  and  implemen¬ 
tation  with  essentially  no  changes.  The  purpose  of  the  material  in 
Chapter  4  is  to  demonstrate  one  way  to  harness  the  processor  protection 
mechanisms  so  that  users  can  define  and  control  the  sharing  of  protected 
subsystems. 

Chapter  5  concludes  the  thesis  by  summarizing  the  important  ideas 
presented  and  indicating  those  areas  where  it  appears  that  further 
research  would  be  fruitful. 

Pelated  Work 

Before  beginning  the  body  of  the  thesis  it  is  appropriate  to  review 
the  published  work  related  to  the  thesis  topic.  The  relationship  of  the 
research  reported  here  to  Multics  has  already  been  discussed  and  the 
pertinent  references  cited.  A  complete  bibliography  of  publications  on 
Multics  appears  in  [5]. 

As  indicated  earlier,  the  concept  of  programming  generality  was 
developed  by  Dennis  [8,9,10].  His  main  concern  has  been  tracing  the 
implications  of  this  concept  on  language  and  system  facilities  for 
manipulating  structured  information.  The  implications  of  programming 
generality  on  protection  mechanisms  are  not  developed  ,.i  his  papers. 
Vanderbilt  [28],  building  on  the  work  of  Dennis,  has  developed  an 
abstract  model  of  information  structures  for  controlling  sharing  in  a 
computer  utility  that  is  consistent  with  the  criterion  of  programming 
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generality.  He  gives  little  consideration  to  methods  of  implementation, 
however,  and  certain  characteristics  of  the  model,  such  as  prohibition 
on  direct  sharing  of  data  among  users  and  the  inability  to  revoke  access 
permission  once  given,  would  be  unacceptable  in  a  practical  facility. 

The  domain  model  finds  its  origin  in  the  spheres  of  protection  of 
Dennis  and  VanHorn  [7].  Lampson  [19,20]  first  recognized  the  power  of 
the  idea  as  an  abstraction  for  understanding  protection  mechanisms,  and 
was  responsible  for  developing  the  idea  into  a  useful  conceptual  tool. 

A  recent  paper  by  Graham  and  Denning  [13]  uses  Lampson* s  model  to 
explain  the  diverse  protection  mechanisms  in  various  existing  systems. 

Aside  from  the  domain  model,  essentially  no  theory  of  protection 
mechanisms  exists.  The  rest  of  the  literature  in  the  field  consists 
of  descriptions  of  proposed  or  existing  systems  wi_h  various  protection 
properties.  Wilkes  [29]  divides  the  various  protection  schemes  into 
two  classes:  list  oriented  mechanisms  and  ticket  oriented  mechanisms. 
With  the  first  approach,  control  of  access  to  an  object  is  specified  in 
lists  maintained  by  the  protected  subsystem  (usually  the  supervisor) 
that  is  the  custodian  of  the  object.  An  attempt  to  access  an  object  is 
validated  by  matching  the  name  of  the  requesting  domain  against  a  list 
of  domains  authorized  to  access  the  object.  Multics  is  an  example  of  a 
system  implementing  sophisticated  list  oriented  protection  mechanisms. 
With  the  second  approach,  permission  to  access  objects  in  the  system 
is  embodied  in  unalterable  tickets  which  may  be  distributed  to  the 
domains  in  the  system.  Presentation  of  the  proper  ticket  is  all  that  is 
required  to  gain  access  to  an  object.  The  CAL  system  [15,18,26,27] 
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allow  multiple  domains  to  be  associated  with  a  single  computation.  In 
the  CAL  system  the  domain  of  execution  is  changed  by  the  explicit  invo¬ 
cation  of  a  special  supervisor  function,  a  method  not  consistent  with 
the  criterion  of  programming  generality.  A  significant  advantage  of 
the  ticket  approach  to  access  control  is  that  only  a  fairly  simple 
mechanism  for  manufacturing  and  controlling  tickets  need  be  embedded  in 
the  most  privileged  part  of  the  supervisor.  With  the  list  approach, 
most  of  the  file  system  must  be  protected  at  this  level.  A  significant 
disadvantage  of  the  ticket  approach  is  the  difficulty  of  revoking  access 
once  a  ticket  has  been  given  to  some  domain  in  the  system.  With  both 
list  and  ticket  oriented  mechanisms  direct  sharing  of  objects  among  the 
domains  in  the  system  can  be  implemented. 

In  addition  to  the  two  basic  classes  of  protection  schemes  suggest¬ 
ed  by  Wilkes  there  exists  a  third  class  which  can  be  called  message 
oriented  mechanisms.  (Actually,  in  some  ways  this  class  is  a  variant 
of  the  list  oriented  mechanisms.)  With  this  approach  no  direct  sharing 
of  objects  is  allowed.  Instead  each  object  is  under  the  exclusive  con¬ 
trol  of  some  process.  All  sharing  is  done  via  interprocess  messages 
that  are  managed  by  the  supervisor.  To  reference  a  data  file  belonging 
to  some  process,  for  example,  another  process  would  send  a  message 
specifying  the  requested  reference.  The  message  is  tagged  by  the  super¬ 
visor  with  the  identity  of  the  sending  process.  The  receiving  process 
decides  on  the  basis  of  this  tag  whether  or  not  the  request  should  be 
honored.  The  result  of  the  request  is  communicated  by  a  return  message. 
The  RC-4000  system  [2]  is  an  example  of  a  message  oriented  system.  While 
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the  message  oriented  mechanisms  have  an  appealing  simplicity,  in 
practice  they  are  awkward  to  work  with  and  inefficient. 

Most  commercially  available  computer  systems  have  fairly  primitive 
protection  facilities  intended  only  to  provide  user  separation.  IBM 
and  other  major  manufacturers  have  recently  become  concerned  about  cer¬ 
tifying  their  systems  so  that  this  total  user  separation  can  be  guaran¬ 
teed.  Aside  from  Multics,  which  is  available  from  Honeywell  as  a  special 
product,  however,  no  operational  or  announced  commercial  system  can 
support  user-defined  protected  subsystems,  and  very  few  even  allow  con¬ 
trolled  sharing  of  programs  and  data  among  users. 

Very  little  work  has  been  done  on  hardware  mechanisms  for  supporting 
sophisticated  protection  mechanisms.  The  protection  facilities  of  most 
systems  are  implemented  largely  in  software  using  hardware  with  fairly 
primitive  protection  mechanisms.  The  machines  of  the  Burroughs  Corpo¬ 
ration  [3]  were  the  first  to  implement  address  mapping  using  segment 
descriptors,  the  technique  that  has  proven  to  be  the  basis  of  most 
sophisticated  protection  hardware.  Evans  and  LeClerc  [11]  were  among 
the  first  to  suggest  that  address  mapping  hardware  including  access 
control  mechanisms  could  be  constructed  to  help  implement  efficiently 
computations  involving  several  domains.  The  hierarchic  domain  structure 
they  propose  is  similar  to  the  model  developed  by  Vanderbilt.  The  Hitac 
5020  [22]  was  one  of  the  first  hardware  processors  to  implement  more 
than  the  simple  supervisor /user  form  of  multiple  domain  protection.  The 
scheme  used  is  patterned  after  the  linearly  nested  domains  of  Multics. 

The  Hitac  processor,  which  closely  follows  the  implementation  suggested 
by  Graham  [14],  is  not  able  to  change  the  domain  of  execution 
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automatical 1y .  The  most  sophisticated  multiple  domain  protection  hard¬ 
ware  that  has  actually  been  constructed  is  embodied  in  the  new  Multics 
processor  [25]  being  built  by  Honeywell.  Several  projects  are  currently 
underway  to  construct  processors  with  similar  protection  mechanisms,  but 
no  published  material  is  available  yet  that  describes  these  efforts. 
Fabry  [12]  has  proposed  hardware  protection  mechanisms  specifically 
designed  to  support  ticket  oriented  protection  mechanisms,  but  which 
provides  little  assistance  with  the  previously  mentioned  problem  of 
locating  already  distributed  tickets  in  order  to  revoke  access. 


CHAPTER  2 


STATIC  ACCESS,  DYNAMIC  ACCESS,  AND-CROSS-DOMAIN  CALLS 

The  hardware  component  of  the  protection  mechanisms  described  in 
this  thesis  is  a  processor  that  supports  a  multidomain  computation  im¬ 
plemented  as  a  single  Multics-like  process.  (Recall  thit  such  a  process 
is  a  single  execution  point  in  a  segmented  virtual  memory.)  This  pro¬ 
cessor  contains  logic  for  implementing  a  segmented  virtual  memory,  for 
enforcing  the  various  virtual  memory  access  constraints  that  represent 
the  encapsulation  of  procedure  and  data  segments  in  several  domains,  and 
for  performing  cross-domain  calls.  In  this  chapter  some  of  the  func¬ 
tional  characteristics  of  this  processor  are  introduced. 

The  major  emphasis  of  the  discussion  is  on  the  types  of  capabil¬ 
ities  the  processor  interprets  and  enforces,  the  dynamic  behavior  of 
these  capabilities,  and  the  steps  involved  in  performing  a  cross-domain 
call.  The  discussion  is  fairly  general,  making  little  reference  to 
specific  implementation  techniques. 
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2.  Each  segment  in  the  virtual  memory  is  identified  by  a  unique 
non-negative  integer. 

3.  The  two-part  address  (s,d)  specifies  Lhe  bit  in  the  seg¬ 
ment  numbered  £. 

4.  All  references  to  memory  generated  by  an  executing  machine 
language  program,  whether  for  indirect  words,  instruction  oper¬ 
ands,  or  the  next  instruction  to  execute,  are  specified  by  two- 
part  addresses.  The  number  of  bits  actually  referenced  by  the 
address  (j>,d)  is  implied  by  the  circumstances  of  the  reference. 

The  processor  logic  required  to  implement  the  segmented  virtual  memory 

of  a  process  is  described  in  the  next  chapter. 

As  indicated  in  Chapter  1,  in  order  for  a  procedure  executing  as 
part  of  a  process  to  reference  a  segment  stored  on-line  in  the  computer 
utility,  the  segment  must  first  be  added  to  the  virtual  memory  of  the 
process.  In  this  chapter  it  is  assumed  that  the  virtual  memory  of  a 
process  somehow  already  contains  all  segments  that  are  to  be  referenced. 


Multiple  Domains 

Each  domain  associated  with  a  process  is  defined  by  a  set  of  capa¬ 
bilities  for  referencing  parts  of  the  segmented  virtual  memory  of  the 
process  in  various  ways.  Methods  for  specifying  which  capabilities  are 
included  in  each  domain  will  be  considered  in  Chapter  4.  The  general 
form  of  any  capability  is: 


1 


3 


\ 

i 

\ 

3 


3 

a 

1 


I 

a 

i 

a 


i 

i 

4 

i 

i 

3 

4 

I 


(name, mode) 

where  the  first  element  identifies  some  object  in  the  system  and  the 
second  element  specifies  the  operations  that  the  capability  allows  to  be 
performed  on  that  object.  With  respect  to  processor  enforced  control  on 
access  to  the  segmented  virtual  memory  of  a  process,  the  relevant  ranges 
of  values  for  names  and  modes  are  fairly  restricted.  All  relevant  names 
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may  be  expressed  as: 

(s,d  ,1) 

where  £  and  d  are  a  two-part  address,  and  _£  is  the  number  of  contiguous 
bits  starting  at  the  named  location.  This  set  of  names  allows  the  iden¬ 
tification  of  any  contiguous  chunk  of  bits  in  any  segment,  i.e.,  any 
subsegment.  The  range  of  values  for  the  mode  is  limited  by  the  archi¬ 
tecture  of  the  processor.  It  is  possible  to  structure  the  mode  to 
individually  control  any  processor  distinguishable  operation  or  set  of 
operations  on  the  contents  of  a  segment.  For  example,  the  use  of  the 
subsegment  named  in  a  capability  as  the  operand  of  each  separate  machine 
instruction  could  be  individually  controlled. 

For  the  purpose  of  encapsulating  procedure  and  data  segments  in  a 
domain,  an  even  more  restricted  set  of  names  and  modes  is  adequate. 

With  the  exception  of  the  gate  capability  introduced  later,  the  capabil¬ 
ities  used  to  express  encapsulation  that  are  recognized  by  the  processor 
name  only  whole  segments  and  allow  independent  control  of  just  three 
operations.  The  operations  are  executing  the  contents  of  a  segment  as 

* 

machine  instructions,  reading  from  a  segment,  and  writing  in  a  segment  . 
The  encapsulation  capabilities  recognized  by  the  processor,  then,  are 


Actually,  capabilities  that  included  no  mode  information  at  all  would 
be  adequate  for  the  purpose  of  encapsulating  procedure  and  data  segments 
in  domains.  In  this  C3se,  the  presence  in  a  domain  of  a  capability 
naming  a  segment  would  permit  full  read,  write,  and  execute  access  to 
the  segment.  Providing  separate  control  on  these  three  operations,  how¬ 
ever,  is  useful  for  several  reasons.  Separate  control  on  reading  and 
writing  encourages  the  sharing  of  procedure  and  data  segments  among 
several  domains  by  making  it  possible  to  share  only  the  ability  to  read 
a  segment.  Separate  control  on  executing  a  segment  allows  the  protec¬ 
tion  mechanisms  of  the  processor  to  detect  accidental  attempts  to 
execute  segments  that  do  not  contain  machine  code. 
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expressed  as: 

(s,m) 

where  £  is  a  segment  number  and  m  is  some  combination  of  read,  write, 
and  execute  permission  flags.  Only  the  combinations  £,  rw,  re.  rwe. 
and  null,  corresponding  to  segments  of  read  only  data,  read/write  data, 
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pure  procedure,  impure  procedure,  and  to  no  access  at  all  ,  respectively 
make  much  sense. 

The  fact  that  the  names  in  these  capabilities  are  segment  numbers 
leads  to  an  especially  convenient  representation  of  the  domains  associa¬ 
ted  with  a  process.  Each  domain  is  represented  as  an  array  whose  ele¬ 
ments  are  the  modes  defining  the  allowed  access  to  the  various  segments 
in  the  virtual  memory  of  the  process.  The  array  is  indexed  by  segment 
number.  (The  usefulness  of  a  null  mode  now  becomes  apparent.)  The 
processor  uses  the  mode  array  corresponding  to  the  c.omain  of  execution 
of  a  process  to  control  virtual  memory  references.  An  attempt  by  an 
executing  machine  language  program  to  read,  write,  or  execute  segment 

number  n  is  allowed  by  the  processor  only  if  the  corresponding  flag 
,  th  , 

appears  m  the  n  mode  in  tms  array. 

Domain  of  Execution 

The  issue  of  how  the  domain  of  execution  of  a  process  is  determined 
now  must  be  considered.  This  problem  is  approached  by  defining  ways  to 
control  changing  the  domain  of  execution.  An  understanding  of  the  sort 
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Including  in  a  domain  a  capability  specifying  null  access  to  a  segment 
is  equivalent  to  having  no  capability  at  all  for  that  segment  in  the 
doma in . 
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of  control  required  can  be  gained  by  reviewing  the  purpose  of  associa¬ 
ting  multiple  domains  with  a  process.  A  domain  provides  the  means  to 
protect  procedure  and  data  segments  from  other  procedures  that  execute 
as  part  of  the  same  ocess.  Using  domains  it  is  possible  to  make  cer¬ 
tain  capabilities  available  only  when  particular  procedure  segments  are 
being  executed.  The  code  sequences  in  these  segments  therefore  deter¬ 
mine  the  use  made  of  those  capabilities.  These  code  sequences  implement 
the  intended  algorithms,  however,  only  if  execution  starts  at  certain 
points.  Thus,  for  domains  to  be  meaningful,  it  must  be  possible  to 
restrict  the  start  of  execution  in  a  particular  domain  to  certain  pro¬ 
gram  locations.  These  locations  are  called  gates.  Changing  the  domain 
of  execution  can  occur  only  as  the  result  of  a  transfer  to  a  gate  loca¬ 
tion  of  another  domain. 

Controlling  the  ability  to  change  the  domain  of  execution,  then, 
requires  devising  capabilities  that  identify  certain  procedure  segment 
locations  as  gates  into  particular  domains.  The  name  in  such  a  capa¬ 
bility  needs  to  be  more  precise  than  just  a  segment  number.  It  must 
identify  a  particular  machine  instruction  in  a  segment.  The  mode  must 
indicate  that  the  named  location  is  a  gate  and  specify  the  name  of  the 
domain  for  which  it  is  a  gate.  Thus,  the  gate  capability  has  the  form: 

(gate  into  domain  D)> 

where  s;  and  d  name  a  virtual  memory  location  and  the  mode  indicates  per¬ 
mission  to  invoke  the  program  section  beginning  at  the  named  location 
and  simultaneously  change  the  domain  of  execution  to  domain  D.  The 
method  of  naming  domains  is  ignored  for  now,  although  it  is  apparent 
from  the  previous  discussion  that  any  domain  naming  scheme  that  allows 
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the  processor  to  find  the  mode  array  for  the  new  domain  of  execution 
will  work. 

Unfortunately,  the  gate  capability  just  described  does  not  fit  very 
well  with  the  previously  suggested  mode  array  representation  of  domains. 
Moving  d  from  the  name  portion  to  the  mode  portion  of  the  capability, 
however,  solves  this  problem,  for  the  name  that  is  left  is  just  a  seg¬ 
ment  number  as  before.  Capabilities  for  all  the  gates  in  a  single  seg¬ 
ment  that  are  accessible  from  some  domain  then  may  be  represented  by 
listing  the  displacements  of  these  gates  in  the  mode  array  element  for 
that  segment.  Less  mode  information  is  required  if  all  these  gate  loca¬ 
tions  in  the  same  segment  are  required  to  be  gates  into  the  same  domain, 
a  reasonable  restriction.  Representing  capabilities  for  gates,  then,  is 
done  by  adding  a  £ate  flag  to  the  other  three  flags  already  possible  in 
mode  array  entries.  If  the  gate  flag  is  present  in  a  particular  entry, 
then  a  list  of  displacements  of  valid  gate  locations  within  the  corres¬ 
ponding  segment  is  also  part  of  the  mode  information,  along  with  the 
name  of  the  domain  for  which  these  locations  are  gates. 

An  Example  of  Mode  Arrays 

Figure  2-1  illustrates  mode  arrays  defining  three  domains  associated 
with  some  process.  Segments  0  and  1  are  read /write  data  segments  access¬ 
ible  only  from  domain  A.  Segments  2  and  3  are  pure  procedure  segments 
executable  only  in  domain  A.  A  program  executing  in  domain  A  can 
change  the  domain  of  execution  to  B  by  transferring  control  to  location 
64  in  segment  4,  and  to  C  through  location  32  in  segment  8.  Domains  B 
and  C  are  similar.  Note  that  segment  6  is  pure  procedure  executable  in 
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both  domains  B  and  C,  and  that  segment  7  is  a  data  segment  that  can  be 
read  and  written  from  domain  B  but  only  read  from  domain  C. 
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Cross -Domain  Calls 

As  discussed  in  Chapter  1,  the  criterion  of  programming  generality 
leads  to  a  pattern  in  which  the  domain  of  execution  of  a  computation  is 
changed  when  one  program  invokes  another  that  requires  execution  in  a 
different  domain.  Adoption  of  this  pattern  means  that  the  gate  capa¬ 
bilities  just  described  will  normally  correspond  to  program  entry  points 
and  that  a  transfer  of  control  to  one  of  these  gate  locations  will  nor- 
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mally  be  part  of  an  interprocedure  call  .  Such  a  call,  however,  in¬ 
volves  several  important  functions  in  addition  to  the  transfer  of  con¬ 
trol  to  an  entry  point,  all  of  which  must  be  handled  properly  if  a 
cross-domain  call  is  not  to  compromise  the  protection  provided  by  either 
of  the  involved  domains.  Some  of  these  additional  functions  lead  to  the 
need  for  the  proces.-or  to  recognize,  manipulate,  and  enforce  capabil¬ 
ities  with  different  dynamic  properties  than  the  encapsulation  capa¬ 
bilities  just  presented,  if  the  processor  is  to  perform  automatically 
cross-domain  calls.  These  new  kinds  of  capabilities  control  the  access 


A  procedure  segment  may  actually  contain  a  set  of  hierarchically  nested 
procedures  permanently  bound  together  Ly  the  compiler.  An  interproce¬ 
dure  call  is  the  call  used  to  invoke  an  entry  point  into  the  outermost 
level  of  such  a  nested  set  of  procedures.  With  the  exception  of  one 
special  circumstance  discussed  later,  entry  points  into  the  inner  layers 
of  such  a  nest  of  procedures  are  not  intended  to  be  invoked  from  inde¬ 
pendent,  separately  compiled  procedures,  and  thus  will  not  be  gate  loca¬ 
tions.  The  calling  methods  used  within  a  procedure  segment  to  invoke 
the  inner  entry  points  are  of  no  concern  to  the  system  or  its  protection 
mechanisms. 


& 


45 


&  i 


of  programs  executing  in  the  called  domain  to  the  arguments  passed  with 
the  call  and  to  the  return  point.  They  must  be  added  to  the  called 
domain  when  a  cross-domain  call  occurs  and  removed  when  the  matching 
return  occurs. 

As  a  basis  from  which  to  develop  the  properties  of  argument  and 
return  capabilities,  the  action  of  an  interprocedure  call  is  considered 
in  more  detail.  An  interprocedure  call  and  return,  as  defined  in  a 
language  like  PL/I,  can  be  broken  into  eight  steps.  The  call  operation 
itself  involves: 

1.  specifying  the  arguments  to  be  passed  to  the  called  procedure; 

rk 

2.  saving  the  current  procedure  activation  record  so  thaL  it  may 
be  restored  when  the  subsequent  return  occurs; 

3.  specifying  the  program  location  to  receive  control  when  the 
subsequent  return  occurs; 

4.  transferring  control  to  the  called  entry  point; 

5.  creating  a  new  activation  record  for  the  called  procedure. 

Once  invoked,  the  called  procedure  will  occasionally  referenr  the  argu¬ 
ments  provided  by  the  calling  procedure.  Eventually,  a  return  of  con¬ 
trol  to  the  calling  procedure  may  occur.  This  return  operation  involves: 

6.  destroying  the  activation  record  of  the  called  procedure; 

7.  transferring  control  back  to  the  return  location  that  was 
specified  by  the  calling  procedure; 

3.  restoring  tu  use  the  activation  record  of  the  calling  procedure. 


The  activation  record,  normally  allocated  in  a  push-down  stack,  is  the 
local  addressing  environment  for  a  procedure  invocation  and  provides 
storage  for  information  associated  with  a  single  invocation  of  a  proce¬ 
dure.  Addresses  of  arguments,  the  address  of  the  return  point,  and  PL/I 
"automatic"  variables  arc  examples  of  this  kind  of  information. 
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The  additional  requirement  of  calls  that  change  the  domain  of  execution 
is  that  all  of  these  steps  take  place  without  compromising  the  protec¬ 
tion  provided  by  either  of  the  domains  involved. 

A  cross-domain  call  occurs  if  the  virtual  memory  location  to  which 
control  is  transferred  in  step  4  happens  to  be  defined  by  a  capability 
in  the  domain  of  execution  (call  it  domain  A)  as  a  gate  into  another 
domain  (call  it  domain  B) .  In  this  case  the  return  point  specified  in 
step  3  and  transferred  to  in  step  7  is  really  a  gate  back  into  domain  A, 
for  a  transfer  to  this  location  by  a  procedure  executing  in  domain  B 
should  change  the  domain  of  execution  back  to  A.  As  seen  earlier,  the 
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may  already  be  in  the  stack.  At  any  given  time,  only  the  return  gate 
capability  at  the  top  of  the  stack  is  available.  When  this  capability 
is  used  to  perform  a  cross-domain  return,  the  processor  removes  it  from 
the  top  of  the  stack,  thereby  making  available  the  next  older  return 
gate  capability.  Thus,  at  any  given  time,  the  only  cross-domain  return 
that  can  be  performed  is  defined  by  the  address  and  domain  name  contain¬ 
ed  in  the  gate  capability  at  the  top  of  the  stack.  This  stack,  then, 
guarantees  that  the  returns  matching  the  sequence  of  outstanding  cross¬ 
domain  calls,  in  the  process  will  occur  in  the  correct  order.,  and  that 
each  such  return  will  transfer  control  to  the  expected  location  and  will 
properly  change  the  domain  of  execution.  This  guarantee  is  valid  even 
if  more  than  one  cross-domain  call  into  some  domain  is  included  in  the 
sequence,  for  procedures  executing  in  one  invocation  of  this  domain  in 
the  sequence  are  not  able  to  use  the  return  capabilities  associated  with 
other  invocations. 

The  capability  for  the  return  gate  of  a  cross-domain  call  is  really 
a  special  case  of  a  capability  for  an  argument  passed  with  a  cross-domain 
call.  Capabilities  to  reference  whatever  arguments  are  specified  in  step 
1  of  the  call  operation  must  be  added  to  the  called  domain  when  the  call 
occurs,  and  must  be  removed  when  the  return  transfer  of  control  in  step 
7  occurs.  The  stack  for  return  gate  capabilities  can  be  expanded  to 
control  the  availability  of  argument  capabilities  as  well.  Thus,  when  a 
cross-domain  call  occurs,  the  processor  allocates  a  stack  frame  at  the 
top  of  this  stack,  pushing-down  whatever  stack  frames  may  already  exist. 
Into  this  frame  the  processor  places  a  capability  for  the  return  gate 
associated  with  the  call  and  capabilities  allowing  reference  to  whatever 
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arguments  are  specified  in  step  1  of  the  call  operation.  Only  the  capa¬ 


bilities  in  the  top  frame  on  the  stack  are  available  at  any  given  time. 


The  top  frame  is  removed,  and  the  remaining  frames  popped-up,  when  a 


cross-domain  return  occurs. 


Static  Access  and 


c  Access 


With  the  addition  of  the  stack  for  argument  and  return  capabilities. 


the  capabilities  that  define  a  domain  of  a  process  are  represented  in 


two  different  ways.  First,  there  is  the  mode  array  of  the  domain  that 


specifies  the  encapsulation  capabilities  of  the  domain.  In  addition. 


whenever  a  particular  domain  is  the  domain  of  execution  of  the  process, 


the  top  frame  on  the  capability  stack  specifies  the  argument  capabili;  -.es 


(including  the  capability  for  the  return  gate)  that  are  temporarily  part 


of  the  domain.  To  differentiate  these  two  sources  of  capabilities  for  a 


domain,  access  available  from  the  encapsulation  capabilities  to  proce¬ 


dures  executing  in  a  domain  is  called  static  ace; ss,  and  that  available 


from  the  argument  capabilities  is  called  dynamic  access.  The  capability 


stack  of  a  process  is  called  the  dynamic  access  stack.  Much  of  the 


rest  of  this  thesis  will  be  concerned  with  the  difference  between  static 


and  dynamic  access,  so  the  reader  is  advised  to  pause  and  be  sure  he 


understands  the  definitions  of  these  concepts. 


The  dynamic  access  stack  is  distinct  from,  though  related  to,  the  stack 
of  activation  records  for  procedure  invocations. 
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and  the  return  point  provided  by  the  calling  procedure.  Since  there  is 
no  control  on  the  specifications  which  may  be  provided,  the  processor 
must  make  sure  that  the  capabilities  created  in  this  way  and  added  to 
the  called  domain  do  not  give  procedures  executing  in  the  called  domain 
permission  to  reference  the  virtual  memory  of  the  process  in  ways  that 
procedures  executing  in  the  calling  domain  cannot.  Without  this  check, 
the  protection  mechanism  of  the  processor  could  be  circumvented  easily 
by  a  pair  of  conspiring  procedures  in  two  different  domains  calling  one 
another  and  specifying  the  creation  of  dynamic  access  capabilities  to 
reference  all  parts  of  the  virtual  memory  of  the  process. 

If  dynamic  access  capabilities  are  to  control  properly  access  to 
arguments,  they  must  provide  more  precise  control  than  the  static  access 
capabilities  discussed  earlier.  In  general,  not  all  arguments  will  be 
whole  segments  of  information.  For  example,  if  the  entire  activation 
record  for  a  procedure  invocation  is  stored  within  one  segment,  then  a 
single  automatic  variable  associated  with  the  procedure  may  occupy  oniy 
a  few  bits  of  that  segment.  It  is  certainly  reasonable  to  specify  such 
a  variable  as  an  argument.  If  dynamic  access  capabilities  are  to  allow 
procedures  executing  in  the  called  domain  access  to  just  the  arguments 
passed  with  the  cross-domain  call,  and  nothing  else,  then  these 
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capabilities  must  be  able  to  name  arbitrary  subsegments,  not  just  whole 
segments  as  do  static  access  capabilities.  The  mode  should  provide 
separate  control  on  reading  and  writing  the  subsegment  named  in  a 
dynamic  access  capability,  so  the  intention  that  the  value  of  a  particu¬ 
lar  argument  not  be  altered  can  be  enforced.  Thus,  the  dynamic  access 
capabilities  recognized  and  enforced  by  the  processor  have  the  form: 

where  the  first  three  elements  name  a  subsegment  and  the  last  element  is 
some  combination  of  read  and  write  permission  flags. 

The  dynamic  access  capabilities  for  return  gates  need  to  contain 
the  same  information  as  static  access  capabilities  for  entry  point  gates. 
The  name  portion  of  a  return  gate  capability  should  specify  the  two-part 
address  of  the  return  location,  and  the  mode  should  indicate  that  the 
capability  is  for  a  return  gate  and  should  specify  the  corresponding 
domain  of  execution.  It  is  very  convenient,  however,  if  the  mode  also 
includes  one  additional  piece  of  information  —  the  two-part  address  of 
the  activation  record  that  is  to  be  restored  to  use  when  the  cross¬ 
domain  return  occurs.  The  calling  procedure  needs  to  be  guaranteed  that 
the  correct  activation  record  is  restored  to  use  when  a  cross-domain 
return  occurs,  as.  well  as  be  assured  that  the  return  transfers  control 
to  the  expected  location  and  changes  the  domain  of  execution  to  the 
proper  domain.  If  procedures  executing  in  the  called  domain  could  some¬ 
how  cause  a  different  activation  record  to  be  restored  to  use,  then  the 
calling  domain  ;ould  be  caused  to  malfunction  after  the  return  occurred. 
As  will  be  seen  in  Chapter  3,  the  activation  record  of  an  executing 
procedure  is  defined  by  the  two-part  address  in  a  particular  addressing 
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register  of  the  processor.  Using  the  extra  information  in  the  return 
gate  capability,  the  processor  can  verify  that  this  register  contains 
the  correct  value  before  performing  a  cross-domain  return.  Thus,  the 
dynamic  access  capability  for  a  return  gate  really  gives  permission  to 
perform  a  very  specific  three-part  operation:  load  the  activation 
record  definition  register  with  a  particular  value,  transfer  control  to 
a  particular  location,  and  change  the  domain  of  execution  to  a  particu¬ 
lar  domain.  As  will  be  seen  in  Chapter  3,  the  return  gate  capability 
may  be  extended  to  control  call  and  goto  operations  to  entry  points  and 
labels,  respectively,  that  are  passed  as  arguments  with  cross-domain 
calls. 


Matching  References  to  Capabilities 

A  virtual  memory  reference  is  specified  by  a  two-part  address 
(j>,d),  an  implied  length  and  an  operation.  Validation  of  such  a 
reference  requires  matching  it  with  some  capability  in  the  domain  of 
execution. 

Matching  a  reference  to  a  static  access  capability  is  quite 
straightforward.  The  segment  number  £  is  used  as  an  index  into  the  mode 
array  for  the  domain  of  execution.  The  read,  write,  execute,  and  gate 
permission  flags  in  the  selected  entry  indicate  in  the  manner  discussed 
earlier  whether  or  not  the  reference  is  allowed,  depending  upon  what 
operation  is  attempted. 

Match* -3  a  reference  tc  a  dynamic  access  capability  is  a  little 
more  complicated: .  Since  more  than  >,v.e  dynamic  access  capability  may 
cover  a  particular  su*  ^grnent,  an  associative  »c-:~ch  of  the  available 
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dynamic  access  capabilities  is  needed.  What  is  required  to  allow  the 
reference  is  the  existence  of  at  least  one  dynamic  access  capability 
covering  the  referenced  subsegment  and  allowing  the  operation  being 
attempted. 

It  is  up  to  the  procedure  in  execution  to  determine  which  of  these 
two  kinds  of  validation  will  be  applied  to  each  virtual  memory  reference. 
The  processor  never  forces  the  use  of  or>r  ->v  he  other  validation  method. 
On  the  other  hand,  it  is  important  to  maintaining  the  integrity  of  a 
domain  to  choose  the  proper  method  of  access  validation  for  each  refer¬ 
ence.  Validation  relative  to  the  dynamic  access  capabilities  in  a 
domain  should  be  used  if  the  reference  represents  an  attempt  to  access 
an  argument  provided  with  a  cross-domain  call.  Otherwise,  the  reference 
should  be  validated  relative  to  the  static  access  capabilities  in  the 
domain.  The  reasons  for  this  pattern  of  validation  will  be  discussed  in 
a  moment. 

The  mechanisms  of  the  processor  for  forming  and  manipulating  two- 
part  addresses  make  it  natural  to  use  the  two  methods  of  access  valida¬ 
tion  in  the  manner  just  suggested.  All  two-part  addresses  that  are  de¬ 
rived  from  the  argument  specifications  associated  with  the  cross-domain 
Call  that  started  execution  in  r,  domain  are  automatically  tagged  by  the 
processor.  A  reference  using  such  a  tagged  address  triggers  validation 
relative  to  the  dynamic  access  capabilities  of  the  domain  of  execution. 
References  with  untagged  addresses  are  validated  relative  co  the  static 
access  capabilities  of  the  domain.  Unless  an  executing  procedure  makes 
an  explicit  effort  to  alter  these  tags,  which  it  can  do,  the  processor 
always  manages  to  identify  correctly  addresses  which  were  derived  from 
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cross-domain  call  argument  specifications,  and  perform  the  proper  vali¬ 
dation  on  references  made  using  such  addresses. 

The  reason  to  be  careful  with  argument-related  addresses  is  that 
they  are  derived  from  information  provided  by  a  procedure  executing  in 
another  domain  —  the  domain  which  generated  the  cross-domain  call.  In 
general,  there  is  no  guarantee  that  they  locate  pieces  of  the  virtual 

ic 

memory  that  are  accessible  from  the  calling  domain  .  For  example,  the 
calling  procedure  could  maliciously  or  erroneously  provide  an  argument- 
related  address  that  in  fact  names  some  location  in  a  critical  data  base 
encapsulated  in  the  called  domain  —  a  lata  base  that  is  not  accessible 
from  the  calling  domain.  If  a  procedure  executing  in  the  called  domain 
writes  through  this  address,  it  does  so  with  the  intention  of  changing 
the  value  of  an  output  argument.  If  this  reference  were  validated 
relative  to  the  static  access  capabilities  of  the  called  domain,  it 
would  succeed,  erroneously  changing  the  critical  data  base.  Validated 
relative  to  the  dynamic  access  capabilities  of  the  domain,  however,  the 
reference  fails,  for  as  setu  earlier  the  dynamic  access  capabilities 
cannot  give  access  permission  that  is  not  also  available  to  the  calling 
domain.  Thus,  dynamic  access  capabilities  allow  the  called  domain  to 
protect  itseif  against  "trick"  argument-related  addresses  provided  by 
the  calling  procedure. 


While  it  is  true  that  some  of  the  addresses  that  can  be  derived  from 
argument  specifications  will  have  been  checked  by  the  processor  when 
used  to  create  the  dynamic  access  capabilities  corresponding  to  cross¬ 
domain  arguments,  as  discussed  earlier,  not  all  such  addresses  will  have 
been  so  checked.  Further,  even  though  the  capabilities  cannot  be  alter¬ 
ed  once  created,  the  specifications  might  be  changed  after  being  checked, 
and  it  is  the  specif ications  from  which  the  called  domain  generates 
argument  addresses.  This  matter  is  discussed  further  in  Chapt*r  3. 
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Creation  of  a  New  Activation  Record 

One  function  that  must  be  performed  by  a  cross-domain  call  has  not 
been  discussed  yet  —  creating  a  new  activation  record  for  the  called 
procedure.  When  a  call  changes  the  domain  of  execution  of  a  process, 
allocation  of  a  new  activation  record  for  the  called  procedure  must 
take  place  without  any  possibility  of  interference  from  the  calling 
procedure.  Therefore,  the  called  procedure  cannot  depend  upon  any  in¬ 
formation  provided  by  the  calling  procedure  in  order  to  find  space  for 
a  new  activation  record. 

Activation  records  are  normally  allocated  in  a  push-down  stack. 

To  prevent  procedures  executing  in  one  domain  from  directly  reading  and 
writing  the  activation  records  (or  their  residues)  of  procedures  that 
execute  in  other  domains,  this  push-down  stack  will  be  spread  over 
several  segments  —  one  for  each  domain  of  a  process.  Static  access 
capabilities  in  the  various  domains  are  usually  arranged  so  that  the 
stack  segment  for  a  particular  domain  can  be  read  and  written  from  that 
domain,  but  is  not  accessible  from  other  domains  except  those  encapsu¬ 
lating  portions  of  the  supervisor. 

With  this  scheme,  allocating  a  new  activation  record  for  the  called 
procedure  involves  finding  the  stack  segment  for  the  domain  of  execution 
of  the  called  procedure  and  then  locating  the  beginning  of  the  free  area 
at  the  end  of  this  segment.  The  processor  makes  this  operation  easy  and 
safe  by  leaving  in  a  particular  addressing  register  after  each  call, 
cross-domain  or  othervise,  the  twc-part  address  of  the  beginning  of  the 
proper  stack  segment  for  the  new  activation  record.  From  this  address 
the  called  procedure  can  easily  locate  the  free  area  at  the  end  of  this 
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segment,  and  allocate  its  own  activation  record,  without  having  to  de¬ 
pend  on  information  provided  by  the  calling  procedure.  This  scheme 
requires  that  there  be  embedded  in  the  processor  some  algorithm  for  gen¬ 
erating  the  segment  number  of  the  proper  stack  segment  given  the  name 
of  the  domain  of  execution. 


A  processor  which  supports  a  multidomain  computation  implemented 
as  a  single  execution  point  in  a  segmented  virtual  memory,  and 
automatically  performs  cross-domain  calls,  must  recognize  and  enforce 
two  distinct  kinds  of  capabilities  —  static  access  capabilities  repre¬ 
senting  the  encapsulation  of  subsystems  in  domains  and  dynamic  access 
capabilities  representing  cross-domain  arguments.  These  two  kinds  of 
capabilities  have  different  dynamic  properties. 

All  functions  of  an  interprocedure  call  have  protection  implica¬ 
tions  when  such  a  call  is  allowed  to  change  the  domain  of  execution. 

The  static  access  capability  for  controlling  access  to  entry  point  gates, 
the  various  dynamic  access  capabilities,  and  processor  assistance  in 
creating  a  new  activation  record  for  the  called  procedure  are  sufficient 
tools  for  performing  these  functions  without  compromising  the  protection 
provided  by  either  domain  involved  ir.  a  cross-domain  call. 

In  the  next  chapter  these  ideas  are  expanded  into  the  design  of  a 
processor  meeting  the  objectives  outlined  in  the  first  chapter.  That 
processor  design  will  enable  many  of  the  ideas  introduced  in  fairly 
general  terms  here  to  be  presented  in  specific  forms  which  make  their 
validity  and  usefulness  more  apparent. 


CHAFTER  3 

THE  PROCESSOR  DESIGN 

This  chapter  describes  a  hardware  processor  that  supports  a  multi¬ 
domain  computation  implemented  as  a  single  execution  point  in  a  segmen¬ 
ted  virtual  memory  and  that  automatically  performs  cross-domain  calls. 
This  processor  provides  a  specific  context  in  which  to  explore  some  of 
the  detailed  implications  of  the  objectives  presented  in  Chapter  1  and 
in  which  to  expand  the  ideas  that  were  introduced  in  Chapter  2. 

The  processor  described  here  is  a  paper  machine.  No  realization 
of  this  design  exists.  It  is  claimed,  however,  that  the  processor 
described  here  could  be  built  economically  using  today's  hardware  tech¬ 
nology  and  that,  if  built,  it  would  provide  a  practical  hardware  base 
for  a  computer  utility.  This  claim  is  based  on  the  facts  that  a  pro¬ 
cessor  with  similar  overall  architecture  but  less  sophisticated  protec¬ 
tion  mechanisms  is  currently  being  built  by  Honeywell  Information 
Systems,  Inc.  to  serve  as  the  primary  component  of  a  new  hardware  base 
for  Multics  [25]  and  that  the  new  protection  mechanisms  described  here 
add  little  to  the  overall  complexity  of  that  machine. 

In  the  case  of  many  of  the  component  mechanisms  in  this  processor, 
the  specific  implementation  described  represents  a  choice  among  several 
alternative  implementations  that  all  meet  the  basic  functional  require¬ 
ments  of  the  component.  An  important  criterion  in  making  such  choices 
was  the  functional  clarity  of  the  various  alternatives.  In  each  case 
the  implementation  chosen  is  intended  to  expose  the  intrinsic  problems 
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that  are  solved  by  a  component  of  the  protection  mechanisms  while  at 
the  same  time  illustrating  that  a  practical,  general  implementation  of 
that  component  is  possible.  For  example,  the  method  used  to  implement 
static  access  capabilities  places  a  fairly  small  fixed  upper  limit  on 
the  number  of  domains  that  can  be  associated  with  a  single  process  at 
any  one  time.  This  implementation  is  easy  to  understand  and  quite 
economic  if  a  small  number  of  fairly  large  domains  are  usually  associated 
with  a  process.  An  alternative  implementation  that  allows  an  essentially 
unlimited  number  of  domains  to  be  associated  with  a  process  was  rejected 
because  it  introduced  complexity  that  obscured  the  intrinsic  problems 
being  solved  by  this  component  of  the  protection  mechanisms  in  the 
processor.  The  specific  design  presented  here,  then,  should  be  consid¬ 
ered  as  one  example  of  how  to  organize  a  processor  to  meet  the  stated 
objectives.  After  understanding  how  this  processor  works,  the  inven¬ 
tive  reader  should  be  able  to  devise  a  large  number  of  variations  on 
this  design  which  embody  the  same  basic  techniques  but  which  may  meet 
better  the  specific  external  constraints  associated  with  a  particular 
application  of  such  a  machine. 

The  Virtual  Memory  and  Static  Access  Capabilities 

As  in  Multics,  the  implementation  of  the  segmented  virtual  memory 
is  based  on  a  descriptor  segment  that  is  stored  in  memory.  Figure  3-1 
illustrates  the  format  of  a  descriptor  segment  entry  (DSE) .  If  the 
validity  bit  (DSE.V)  is  on.  then  a  DSE  contains  the  absolute  address  of 
the  beginning  of  a  segment  in  memory  (DSF.. ADDRESS)  and  the  length  of 
of  that  segment  (DSE . LENGTH ) .  The  descriptor  segment  base  register  (DSBR) 


58 


Descriptor  segment  base 


register 


DSBR  ADDRESS  LENGTH 


Domain  of  execution  register 


Descriptor  segment  (stored  in  memory) 
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Figure  3-1:  The  descriptor 


segment  and  related  registers. 
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of  the  processor  contains  the  base  address  (DSBR. ADDRESS)  and  length 
(DSBR. LENGTH)  of  the  descriptor  segment,  allowing  the  address  transla¬ 
tion  logic  of  the  processor  to  reference  DSE's  by  absolute  address. 
Automatic  translation  of  a  two-part  address  inLo  the  corresponding 
absolute  address,  done  by  using  the  segment  number  as  an  index  with 

if 

which  to  retrieve  the  appropriate  DSE  ,  happens  each  time  that  the 
virtual  memory  is  referenced,  i.e.,  each  time  an  instruction,  indirect 
address,  or  instruction  operand  is  referenced  by  the  executing  program. 

If  each  process  is  to  have  its  own  virtual  memory,  as  in  Multics,  then 
each  process  has  its  own  descriptor  segment.  If  several  processes  are 
to  share  a  single  virtual  memory,  then  those  processes  have  a  common 
descriptor  segment. 

As  implied  by  this  description,  it  is  assumed  that  the  storage 
space  for  each  segment  is  contiguously  allocated  in  a  one- level  memory 
system  with  enough  capacity  to  hold  all  segments  of  interest.  With  most 
real  implementations  of  segmented  virtual  memories,  storage  for  segments 
is  provided  by  a  multilevel  memory  system  using  block  allocation  and 
paging.  If  used,  block  allocation  and  paging  must  be  taken  into  account 
by  the  address  translation  logic  of  the  processor.  When  properly  imple¬ 
mented,  however,  these  storage  management  techniques  are  functionally 
transparent  from  the  point  of  view  of  protection  mechanisms.  The  assump¬ 
tion  of  a  one-level  memory  system  and  contiguous  allocation  of  space  for 
segments  allows  problems  of  storage  management  to  be  ignored. 


Including  in  the  processor  a  small,  fast  associative  memory  for  the 
most  recently  used  DSE's  can  eliminate  most  of  the  memory  references  for 
DSE's  [24], 
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As  indicated  in  Chapter  2,  the  static  access  capabilities  included 
in  the  domains  associated  with  a  process  can  be  represented  as  mode 
arrays,  one  per  domain.  Mode  arrays  are  indexed  by  segment  number,  as 
is  the  descriptor  segment.  This  suggests  the  straightforward  implemen¬ 
tation  for  static  access  capabilities  of  combining  the  mode  arrays  of  a 
process  with  the  descriptor  segment.  The  DSE  format  in  Figure  3-1 
illustrates  this  implementation.  Each  DSE  contains  a  set  of  read,  write, 
execute,  and  gate  permission  flags  for  each  domain  that  can  be  supported 
by  the  processor.  The  domain  of  execution  register  (DR)  records  the 
number  of  the  currtnt  domain  of  execution  of  the  process.  The  value  in 
DR  is  used  to  select  the  proper  set  of  permission  flags  with  which  to 
validate  virtual  memory  references. 

The  DSE  for  a  segment  is  an  ideal  place  in  which  to  record  the 
static  access  capabilities  controlling  references  to  that  segment. 

Since  the  processor  must  examine  the  DSE  for  a  segment  each  time  that 
segment  is  referenced  anyway,  little  effort  is  added  to  validate  an 
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attempted  access  against  static  access  capabilities  recorded  there. 

With  this  implementation  of  static  access  capabilities,  changes  in  the 
static  access  of  a  domain  can  be  made  immediately  effective,  since 
access  is  validated  each  time  a  reference  is  made. 

A  key  engineering  decision  is  the  number  of  domains  that  will  be 
supported  automatically  by  the  processor.  The  size  of  a  DSE  increases 
as  the  number  of  domains  to  be  supported  increases.  Based  on  experience 


If  an  associative  memory  for  DSE's  is  used,  the  static  access  capa¬ 
bilities  for  a  segment  will  automatically  be  in  the  associative  memory 
whenever  the  corresponding  DSE  is  there. 
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with  Multics,  the  number  chosen  here  is  eight.  Thus,  there  are  32  per¬ 
mission  flags  in  each  DSE.  This  choice  is  based  upon  the  assumption  that 

domains  normally  encapsulate  relatively  large  subsystems  and,  therefore, 

* 

that  a  tew  domains  per  process  is  sufficient. 

Whenever  DR  contains  the  value  n.  the  n^  set  of  flags  in  the  DSE's 
control  access  to  the  virtual  memory  of  the  process.  An  attempt  to  read 
or  write  segment  number  £  will  be  allowed  only  if  DSEjs.Rii  or  DSEjJ.Wn  is 
set  on,  respectively.  An  attempt  to  transfer  control  to  location  (j?,d) 
has  three  possible  results.  If  both  DSE_s.En  and  DSE^.Gn  are  off,  then 
the  transfer  is  not  allowed.  If  DSEji.En  is  on,  then  the  transfer  is 
allowed  and  execution  continues  in  the  same  domain.  If  DSEji.Gn  is  on. 
then  t"'  segment  contains  gates  into  another  domain.  The  displacements 
of  th  ate  locations  are  recorded  in  DSE. GATES,  and  the  name  of  the 

dcmai.  ?  recorded  in  DSE. DOMAIN.  For  ease  of  representation,  all  gate 

locnt.  in  a  segment  are  collected  together  at  the  beginning  of  the 
segment  AGATES  indicates  the  number  of  such  gate  locations.  Thus, 
d  <  DSE£. GATES  guarantees  that  the  transfer  is  to  a  gate  location.  If 
this  check  is  true,  then  DR  is  changed  to  the  value  recorded  in 
DSEjj. DOMAIN,  thus  changing  the  domain  of  execution  of  the  process,  and 
the  transfer  is  allowed.  Having  both  DSE^.En  and  DSEs^.Gn  set  on  is  not 
meaningful . 


An  alternative  implementation  of  static  access  capabilities  is  to  place 
the  mode  array  for  each  domain  in  a  separate  segment.  This  implementa¬ 
tion  removes  the  small  fixed  upper  limit  on  the  number  of  domains  that 
may  be  associated  with  a  process  at  any  one  time,  but  complicates  the 
naming  of  domains,  the  representation  of  gates,  and  the  structure  of 
the  associative  memory  for  DSE’s. 

Best  Available  Copy 


By  hardware  and  software  convention,  domain  0  is  always  used  to 
encapsulate  the  most  privileged  portion  of  the  supervisor.  Instructions 
designated  as  privileged  will  be  executed  by  the  processor  only  in 
domain  0.  The  instruction  to  load  DSBR  is  an  example  of  an  instruction 
that  must  be  privileged  in  order  to  maintain  the  integrity  of  the  pro¬ 
tection  mechanisms  in  the  system.  The  seven  remaining  domain  numbers 
available  to  a  process  are  managed  by  the  supervisor  in  much  the  same  way 
that  the  larger  number  of  available  segment  numbers  are  managed.  When  a 
program  executing  as  part  of  a  process  first  wants  to  reference  some 
segment  stored  on-line,  the  segment  is  assigned  an  available  segment 
number  in  the  virtual  memory  of  the  process  by  the  supervisor.  Likewise, 
when  a  program  first  wishes  to  associate  with  the  process  some  protected 
subsystem  whose  definition  is  stored  on-line,  that  protected  subsystem 
is  assigned  an  available  domain  number  by  the  supervisor.  Thus,  while 
the  maximum  number  of  protected  subsystems  may  be  associated  with  a 
process  at  one  time  is  eight,  the  particular  eight  can  change  with  time, 
and  different  sets  of  eight  or  fewer  protected  subsystems  can  be  asso¬ 
ciated  with  processes  that  have  different  virtual  memories. 

Generat ing  Virtual  Memory  Addresses 

In  order  to  understand  the  discussion  to  be  presented  in  the  follow¬ 
ing  sections  of  this  chapter,  i*-  is  necessary  to  know  something  about  the 
generation  of  two-part  addresses  by  machine  language  programs.  For  ease 
of  description,  the  processor  presented  here  is  primarily  a  word 
addressed  machine.  Thus,  the  displacement  portion  of  a  two-part  address 
is  a  v;ord  number,  where  a  word  is  enough  bits  to  hold  an  indirect 
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address  or  an  instruction,  and  the  implied  length  of  most  references  is 
one  word.  The  ideas  presented  here,  however,  can  also  be  applied  easily 
to  a  byte  or  bit  addressed  machine.  The  ultimate  precision  of  referenc¬ 
ing  memory  by  arbitrary  bit  number  and  arbitrary  bit  length  can  be  very 
useful  in  controlling  access  to  cross-domain  arguments  that  are  not  word 
aligned,  and  will  be  considered  in  that  respect  later. 

A  two-parr  address  together  with  a  protection  tag  is  called  a 
pointer.  The  tag  portion  of  a  pointer  is  a  one  bit  flag  that  indicates 
whether  the  static  access  capabilities  or  the  dynamic  access  capabilities 
of  the  domain  of  execution  should  be  used  to  validate  references  through 
the  pointer.  The  tag  will  be  considered  in  more  detail  in  a  moment. 
Figure  3-2  presents  the  registers  and  storage  formats  relevant  to  manip¬ 
ulating  pointers.  The  instruction  pointer  register  (IPR)  specifies  the 
two-part  address  of  the  instruction  being  executed.  Since  instruction 
retrieval  is  always  validated  relative  to  the  static  access  capabilities 
of  the  domain  of  execution,  the  pointer  in  IPR  does  not  include  a  tag. 
Arbitrary  pointers  may  be  kept  in  the  pointer  registers  (PR1,  PR2,  ...) 
or  stored  in  memory  as  indirect  addresses  (IND).  Because  segment 
numbers  cannot  be  known  when  a  procedure  segment  is  compiled  and  because 
most  procedure  segments  will  be  p’  ~e3  instructions  (INST)  specify 
operand  addresses  by  giving  an  offset  (INST. OFFSET)  relative  co  IPR  or 
one  of  the  PR's.  INST.PRNUM  =  0  indicates  IPR-relative  addressing  and 
INST.PRNUM  >  0  indicates  PR-relative  addressing.  In  the  latter  case 
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The  one  bit  tag  is  a  simplification  used  now  to  facilitate  the  descrip¬ 
tion  of  the  processor.  The  multibit  tag  actually  required  will  be  intro¬ 
duced  later. 


Instruction  pointer  register 


SEGNO 


WORDNO 


Pointer  registers 
PR1  TAG 
PR2 


TAG 

SEGNO 

WORDNO 

Indirect  address  (stored  in  memory) 


IND  TAG  SEGNO 


WORDNO 


Instruction  (stored  in  memory) 

INST  |  PRNOmI  OFFSET  OPCODE  I 


Temporary  pointer  register 
TPR  ItAG  1  SEGNO 


WORDNO 


Figure  3-2:  Register  and  storage  formats  for  address  formation 


the  value  of  the  field  indicates  which  PR.  Indirect  addressing  may  be 
specified  by  setting  the  indirect  flag  (INST. I)  on.  The  final  item  in 
Figure  3-2  is  the  temporary  pointer  register  (TPR).  This  is  an  internal 
processor  register  that  is  not  directly  program  accessible.  In  TPR  is 
formed  the  two-part  address,,  called  the  effective  pointer,  of  the 
operand  of  each  instruction. 

The  algorithm  for  generating  the  effective  pointer,  given  an 
instruction,  is  presented  in  Figure  3-3.  Ignoring  tags  in  pointers  for 
a  moment,  a  couple  of  examples  will  make  clear  the  operation  of  this 
algorithm.  The  instruction: 


PRNUM 

OFFSET 

OPCODE 

I 

0 

200 

ADD  ! 

off  I 

specifies  that  its  operand  is  the  word  200  beyond  the  instruction  in 
the  same  segment.  The  instruction: 


1 

200 

ADD 

off 

specifies  that  its  operand  is  the  word  200  beyond  the  location  specified 
by  the  pointer  in  PR1.  The  instruction: 


200 


ADD 


on 


causes  the  word  200  beyond  that  specified  by  the  pointer  in  PR1  to  be 
retrieved  from  memory  and  interpreted  as  an  indirect  address  which 
specifies  the  two-part  address  of  the  instruction’s  operand.  The  instruc¬ 
tions  from  these  three  examples  may  be  written  as: 

ADD  ‘200 
ADD  FRlt200 
ADD  PR1I200,* 


respectively. 
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Obviously,  for  this  machine  reallj  to  be  practical  a  richer  collec¬ 
tion  of  addressing  techniques  would  be  needed.  The  processor  as 
described  does  not  even  have  index  registers;  The  techniques  shown, 
however,  are  sufficient  to  discuss  the  protection  issues  raised  in  this 
thesis  and  to  illustrate  the  rules  that  other  addressing  techniques  must 
follow.  With  respect  to  protection  mechanisms,  it  is  straightforward  to 
add  other  more  sophisticated  addressing  techniques  to  the  processor. 

Two  machine  instructions  are  representative  of  those  used  to  manip¬ 
ulate  pointers.  The  "effective  pointer  to  pointer  register  n"  i-  truc- 
tion  (EPPn)  causes  the  effective  pointer  generated  by  the  instruction, 
i.e.,  the  entire  contents  of  TPR,  to  replace  the  contents  of  PRn. 

"Store  pointer  from  pointer  register  n"  (SPPn)  causes  the  entire  contents 
of  PRn  to  be  stored  at  the  specified  location  in  the  format  of  an  in¬ 
direct  address.  As  an  example  of  how  these  two  instructions  can  be  used, 
note  that  the  following  code  sequence  saves  the  pointer  from  PR4  and  then 
restores  it  to  PR4: 

SPP4  PRU367 
EPP4  PRl‘367,* 

The  role  of  the  tags  in  pointers  is  now  discussed  in  more  de:ail. 

The  tag  differentiates  pointers  related  to  cross-domain  argumer1  >  from 
other  pointers.  When  the  tag  in  a  pointer  is  off  it  means  that  a 
reference  through  that  pointer  will  be  validated  relative  to  the  static 
access  capabilities  of  the  domain  of  execution.  When  the  tag  is  on  the 
dynamic  access  capabilities  of  the  domain  of  execution  will  be  used 


instead . 
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The  processor  is  organized  so  that,  as  a  matter  of  course,  the  tag 
is  on  in  all  pointers  related  to  cross-domain  arguments.  The  key  to 
this  feature  is  the  effective  pointer  generation  algorithm  presented  in 
Figure  3-3.  It  is  the  tag  in  TPR  that  determines  which  type  of  access 
validation  will  be  applied  to  each  indirect  address  reference  and  each 
instruction  operand  reference.  As  can  be  sear,  from  Figure  3-3,  the  tag 
in  TPR  will  be  on  at  the  conclusion  of  effective  pointer  generation  for 
some  instruction  if  the  operand  address  specification  in  the  instruction 
indicates  a  PR  whose  tag  is  on  or  locates  in  indirect  address  whose  tag 
is  on  or  both.  A  reference  to  an  indirect  address,  if  required,  will  be 
validated  as  indicated  by  the  value  of  TPR. TAG  at  the  point  in  the 
algorithm  where  the  indirect  address  is  retrieved  from  memory. 

The  technique  described  in  the  next  section  for  transmitting  argu¬ 
ments  on  a  call  is  to  prepare  a  list  of  indirect  addresses  locating  the 
various  arguments  and  then  to  communicate  the  location  of  this  list  to 
the  called  procedure  via  a  ?R.  In  the  case  of  a  cross-domain  call  the 
processor  automatically  sets  the  tag  in  this  PR  on.  Since  the  called 
procedure  normally  will  derive  the  addresses  of  the  arguments  through 
this  PR  using  the  effective  pointer  generation  algorithm  just  described, 
all  argument-related  addresses  will  acquire  a  tag  that  is  on  as  a  matter 
of  course,  and  therefore  all  references  to  cross-domain  arguments  will 
be  validated  relative  to  the  dynamic  access  capabilities  of  the  called 
domain  as  is  desired.  Referencing  cross-domain  arguments  will  be  dis¬ 
cussed  in  more  detail  later. 
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Call  and  Return 

The  next  step  in  describing  the  processor  is  to  introduce  the 
implementation  of  the  standard  interprocedure  call  and  return.  This 
call  and  return  convention  provides  the  standard  interface  for  separately 
compiled  procedures  in  the  system  so  that  they  may  be  used  as  building 
blocks  in  the  manner  discussed  in  Chapter  1.  For  this  initial  descrip¬ 
tion  protection  issues  are  ignored. 

According  to  Chapter  2,  the  first  step  of  an  interprocedure  call  is 
specifying  the  arguments  to  be  passed  to  the  called  procedure.  Follow¬ 
ing  the  custom  in  many  programming  languages,  the  procedure  to  be  called 

is  assumed  to  know  the  number  of  arguments  to  be  passed,  the  order  in 

* 

which  they  wiil  be  specified,  and  the  type  and  size  of  each.  Since 
arguments  are  to  be  passed  by  address,  the  minimum  information  which  must 
be  communicated  to  the  called  procedure  is  a  list  containing  a  pointer 
to  the  start  of  each  argument.  To  communicate  this  list  a  specific 
pointer  register  chosen  by  system  convention  (call  it  PRa)  is  set  to 
point  to  an  area  of  memory  that  is  to  hold  the  list.  This  area  is 
allocated  in  the  activation  record  of  the  calling  procedure.  The  area 
is  then  filled  according  to  the  format  given  in  Figure  3-4  with  pointers 
to  the  various  arguments  in  the  appropriate  order.  The  pointer  to  the 
argument  normally  is  constructed  using  a  code  sequence  such  as: 

EPPri  "argument  _i" 

SPPn  PRa*  (2J.+3) 


These  assumptions  can  be  removed  by  providing  a  more  elaborate  argument 
list  than  is  defined  here.  The  simple  argument  list  presented  is  ade¬ 
quate  to  illustrate  the  relevant  protection  issues. 
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where  n  indicates  some  PR  that  is  temporarily  free  and  "argument  _i" 
represents  an  operand  address  specification  locating  the  i*"*1  argument. 

The  next  two  steps  of  a  call  are  saving  a  pointer  to  the  current 
activation  record  and  specifying  the  return  location.  The  beginning  of 
the  memory  area  holding  the  activation  record  in  use  is  specified  by 
another  pointer  register  chosen  by  system  convention  (call  it  PRs) .  The 
return  location  is  always  one  word  beyo'.d  the  instruction  that  transfers 
control  to  the  called  procedure.  The  instructions: 

SPPs  PRat2 

EPPn  t3 

SPPn  FRatl 

where  n  designates  some  unused  PR,  create  the  return  block  at  locations 
1  and  2  of  the  argument  list  as  shown  in  figure  3-4  by  storing  as  in¬ 
direct  addresses  the  pointer  from  PR^  and  the  pointer  from  IPR  (suitably 
offset) . 

Creating  the  argument  list  also  includes  storing  additional  argu¬ 
ment-related  information  in  the  empty  words  shown  in  Figure  3-4.  This 
extra  information  is  used  by  the  processor  in  the  case  of  a  cross-domain 
call  to  create  the  proper  dynamic  access  capabilities.  The  definition 
of  these  remaining  parts  of  the  argument  list  is  delayed  until  the  next 
section. 

Once  the  argument  list  is  created,  the  next  step  of  the  call  is 
actually  performing  the  transfer  of  control  to  the  called  entry  point. 
This  is  done  by  executing  the  instruction: 

CALL  "entry  point" 

where  "entry  point"  is  an  operand  address  specification  that  locates  the 
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entry  point  being  called.  In  addition  to  transferring  control,  the 
CALL  instruction  helps  the  called  procedure  create  a  new  activation 
record  for  itself  by  leaving  a  third  pointer  register  chosen  by 

system  convention  (call  it  PRb)  a  pointer  to  the  zeroth  word  of  the 
stack  segment  in  which  the  called  procedure  should  allocate  its  activa¬ 
tion  record.  This  stack  segment  has  in  its  zeroth  word  a  pointer  to  the 
beginning  of  the  unused  area  at  the  end  of  the  stack  segment.  The  called 
procedure  creates  a  new  activation  record  of  _£  words  there  by  executing 
the  instructions: 

EPPs  PRb tO,* 

EPPn  PRs t i 

SPPn  PRb *0 

where  n  designates  some  PR  other  than  one  of  the  three  reserved  pointer 
registers.  The  first  instruction  loads  PRj;  with  a  pointer  to  the  be¬ 
ginning  of  the  new  act  •  ion  record.  The  second  and  chird  instructions 
update  the  pointer  in  the  base  of  the  stack  segment  to  point  just  beyond 
this  new  activation  record. 

Creating  a  new  activation  record  completes  the  steps  of  the  call 
operation.  While  executing,  the  called  procedure  may  reference  words  in 
its  activation  record  using  operand  address  specifications  of  the  form 
"PRs/J/'  in  instructions.  It  can  generate  in  PRn  the  beginning  address 
of  the  argument  using  the  instruction: 

EPPii  r Ra  ‘  ( 2J.+3  )  , * 

When  it  comes  time  to  return,  the  called  procedure  must  perform  the 
three  steps  of  the  return  operation.  First,  its  activation  record  must 
be  released  and  added  to  the  unused  area  at  the  end  of  the  stack  segment. 


This  is  done  with  the  single  instruction: 


SPPs  PRbtO 


which  resets  the  pointer  in  the  base  of  the  stack  segment  to  point  at 
the  beginning  of  the  released  activation  record.  The  second  and  third 
steps  of  the  return  operation  are  transferring  control  back  to  the 
calling  procedure  and  restoring  to  use  the  activation  record  of  the 
calling  procedure.  These  steps  are  performed  in  reverse  order  by  the 
following  instruction  sequence: 

EPPs  PRa  *  2 , * 

RETURN  PRa t 1 ,  * 

The  first  instruction  restores  to  PRs  the  activation  record  pointer 
from  the  return  block  in  the  argument  list.  The  second  instruction* 
transfers  control  to  the  location  specified  by  the  return  pointer  from 
the  return  block.  Thus,  the  calling  procedure  receives  control  at  the 
proper  return  point  and  the  proper  activation  record  is  restored  to  use. 

Note  that  the  only  PR  which  is  restored  by  the  return  operation  to 
the  value  it  contained  prior  to  the  call  is  PR£.  It  is  up  to  the  call¬ 
ing  procedure  to  explicitly  save  and  restore  other  PR's  whose  contents 
are  valuable.  Because  PR^  is  automatically  restored  by  the  return,  the 
activation  record  can  be  used  by  the  calling  procedure  as  a  place  in 
which  to  save  the  values  of  other  PR's  before  the  call,  from  which 
place  they  may  be  restored  after  the  return. 


Ignoring  protection  issues,  the  RETURN  instruction  simply  transfers 
control  to  the  location  specified  as  its  operand.  As  will  be  seen  in 
the  next  section,  however,  the  RETURN  instruction  can  perform  some 
protection-related  operations  that  normal  transfer  instructions  cannot. 
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Cross-Domain  Call  and  Return 


The  standard  interprocedure  call  and  return  just  sketched  are  now 
reconsidered  in  light  of  the  requirement  that  they  be  able  to  change  the 
domain  of  execution  of  the  process.  The  overall  strategy  of  implement¬ 
ing  cross-domain  calls  and  returns  is  .  J  on  the  following  two  hard¬ 
ware  enforced  restrictions: 


1.  Only  the  CALL  instruction  may  utilize  a  static  access  capability 
for  an  entry  point  gate. 


2.  Only  the  RETURN  instruction  may  utilize  a  dynamic  access  capa¬ 
bility  for  a  return  gate. 


The  implications  of  these  restrictions  are  that  all  cross-domain  calls 
will  be  performed  by  the  CALL  instruction,  and  that  all  cross-domain 
returns  will  be  performed  by  the  RETURN  instruction.  (The  processor  is 
also  arranged  so  that  no  other  type  of  instruction  may  change  the  domain 
of  execution  of  a  process.)  Thus,  the  special  functions  associated 
with  cross-domain  calls  and  returns  can  be  embedded  in  the  CALL  and 
RETURN  instructions,  respectively,  with  the  assurance  that  these  func¬ 
tions  will  be  performed  whenever  a  cross-domain  call  or  return  occurs. 

If  a  call  to  location  (£,d)  from  domain  n  is  to  be  cross-domain, 
then  the  CALL  instruction  detects  this  circumstance  by  noting  that 

ic 

DSEs^.Gn  is  on  rather  than  DSE^.En.  (The  call  will  be  allowed  if 
d  <  DSEs. GATES  and  the  new  domain  of  execution  will  be  DSEs^. DOMAIN. ) 
Detection  of  a  cross-domain  call  causes  the  CALL  instruction  to  perform 


It  is  assumed  for  most  of  this  chapter  that  the  effective  pointer  gener¬ 
ated  by  the  CALL  instruction  always  has  a  tag  that  is  off,  and  thus  that 
validation  of  the  call  is  relative  to  the  static  access  capabilities  of 
the  domain  of  execution.  In  one  of  the  last  sections  of  the  chapter 
the  meaning  of  removing  this  restriction  is  explored. 
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two  extra  operations  that  are  not  performed  if  the  call  does  not  change 
the  domain  of  execution.  The  first  is  creating  a  new  frame  on  the 
dynamic  access  stack  of  the  process  and  filling  this  frame  with  the 
dynamic  access  capabilities  which  will  allow  procedures  executing  in  the 
called  domain  to  reference  the  arguments  of  the  call  and  transfer  control 
back  to  the  return  gate.  The  second  extra  operation  is  to  set  the  tag 
in  the  argument  list  pointer  register  (PRa.TAG)  to  on  so  that  references 
to  the  cross-domain  arguments  by  procedures  executing  in  the  called 
domain  will  be  validated  with  respect  to  these  dynamic  access  capa¬ 
bilities,  rather  than  the  static  access  capabilities  of  the  called 
domain.  After  performing  these  two  extra  steps  in  the  case  of  a  cross¬ 
domain  call,  the  CALL  instruction  completes  in  the  normal  manner  by 
loading  PRb  with  a  pointer  to  the  base  of  the  stack  segment  in  which 
the  called  procedure  should  allocate  its  new  activation  record,  and 
then  transferring  control  to  the  called  location.  The  pointer  in  PRb 
is  created  the  same  way  whether  the  call  is  cross-doroann  or  not.  The 
stack  segment  selection  rule  embedded  in  the  processor  is  that  the 
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stack  segment  for  domain  n  is  segment  number  n.  Thus,  PRb. SEGNO  is 
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This  stack  segment  selection  rule  is  adequate  only  for  the  case  that 
each  process  has  its  own  virtual  memory.  If  it  is  desired  to  allow 
multiple  processes  with  the  same  virtual  mamory,  i.e.,  more  than  one 
execution  point  in  a  virtual  memory,  then  a  more  sophisticated  stack 
segment  selection  rule  is  required  to  provide  each  of  the  processes 
sharing  a  virtual  memory  its  own  set  of  stack  segments.  A  simple  way 
to  provide  for  multiple  sets  of  stack  segments  in  a  virtual  memory  is 
to  include  ir.  the  processor  a  register  that  specifies  the  eight  con¬ 
secutively  numbered  segments  that  are  the  stack  segments.  When  a 
CALL  instruction  is  executed,  then  PRb. SEGNO  is  calculated  by  adding 
the  new  domain  number  to  the  value  in  this  stack  segment  selection 
register.  The  various  processes  sharing  a  virtual  memory  each  would 
execute  with  a  different  value  in  this  register,  and  thus  each  would 
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set  to  the  number  of  the  domain  in  which  the  called  procedure  will 
execute,  PRb.WORDNO  is  set  to  zero,  and  PRb.TAG  is  set  off  (the  called 
procedure  will  use  static  access  tc  reference  this  stack  segment).  The 
transfer  of  control  to  the  called  procedure  is  done  by  loading  IPR  from 
the  effective  pointer  generated  by  the  CALL  and,  if  necessary,  reloading 
DR  to  change  the  domains  of  execution. 

A  cross-domain  return  is  detected  by  noting  that  the  tag  is  c>n  in 
the  effective  pointer  generated  by  the  RETURN  instruction.  Detection  of 
a  cross-domain  return  causes  the  RETURN  instruction  to  perform  several 
extra  operations  that  are  not  performed  if  the  return  does  not  change 
the  domain  of  execution.  The  return  gate  capability  in  the  newest  frame 
on  the  dynamic  access  stack  is  used  to  verify  that  PRs  contains  the 
proper  activation  record  pointer  and  that  the  transfer  is  to  the  proper 
location.  If  so,  the  RETURN  instruction  removes  this  frame  from  the 
dynamic  access  stack,  thus  destroying  the  dynamic  access  capabilities 
that  allowed  procedures  executing  in  the  called  domain  to  reference  the 
arguments  of  the  corresponding  cross-domain  call  and  transfer  control 
to  the  return  gate.  When  the  effective  pointer  generated  by  the  RETURN 
instruction  is  loaded  into  IPR  to  perform  the  transfer,  DR  is  changed 
back  to  the  domain  of  execution  of  the  calling  procedure,  as  recorded 
in  the  return  gate  capability. 


have  its  own  set  of  stack  segments.  With  this  change  the  processor  is 
fully  able  to  support  multiple  processes  sharing  a  single  virtual 
memory.  Each  such  process  would  have  its  own  dynamic  access  stack  but 
would  use  the  same  descriptor  segment. 
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Access  Capapilities 


In  creating  a  new  dynamic  access  stack  frame  for  a  cross-domain 
call,  the  CALL  instruction  uses  the  standard  interprocedure  argument 
list  as  the  specification  from  which  to  generate  dynamic  access  capa¬ 
bilities.  The  argument  list  defined  in  Figure  3-4,  while  it  provides 
enough  information  for  the  called  procedure  to  reference  the  arguments, 
does  not  provide  quite  enough  for  the  processor  to  create  the  proper 
dynamic  access  capabilities.  Spaces  have  been  left  in  that  format,  how¬ 
ever.  for  the  additional  information  required  to  correct  this  deficiency. 
The  complete  argument  list  format,  illustrated  in  Figure  3-5,  uses  a 
double  word  entry  to  describe  each  argument.  This  entry  contains  the 
size  (in  words)  of  the  argument  and  flags  indicating  whether  the  argu¬ 
ment  can  be  read  and/or  written,  in  addition  to  the  pointer  to  the 
beginning  of  the  argument.  To  inform  the  processor  how  many  dynamic 
access  capabilities  to  generate,  an  argument  list  header  is  added  that 
indicates  the  length  (in  words)  of  the  list. 

To  be  consistent  with  the  criterion  of  programming  generality,  the 
full  argument  list  as  defined  in  Figure  3-5  must  be  generated  by  com¬ 
piled  code  for  all  interprocedure  calls,  as  it  cannot  be  known  in  ad¬ 
vance  which  calls  will  be  cross-domain.  Minor  extensions  to  most 
languages  will  be  required  to  allow  symbolic  programs  to  specify  to  the 
compiler  which  arguments  of  a  call  are  input  arguments  and  which  are 
output  arguments  so  that  the  read  and  write  flags  in  the  argument  list 
entries  can  be  properly  set.  Compilers  must  .:Iso  be  able  to  generate 
code  which  properly  sets  the  size  information  in  each  argument  list 


entry. 


Figure  3-5:  Completed  argument  list  format  for  an  interprocedure  call 
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The  dynamic  access  stack  (DAS)  of  a  process,  in  which  dynamic 
access  capabilities  are  created  by  the  processor  on  a  cross-domain  call, 
is  located  in  memory  —  presumably  in  a  segment  that  can  be  read  and 
written  directly  only  from  domain  0.  The  location  and  state  of  the  DAS 
is  specified  by  the  DAS  definition  register  (DASDR)  shown  in  Figure  3-6. 
This  register,  in  addition  to  being  manipulated  by  the  CALL  and  RETURN 
instructions  in  the  case  of  cross-domain  calls  and  returns,  can  be  loaded 
and  stored  directly  by  privileged  instructions.  DASDR. SEGNO  and 
DASDR. W0RDN01  specify  the  two-part  address  of  the  beginning  of  the  most 
recently  created  DAS  frame.  DASDR. W0RDN02  specifies  the  word  one  beyond 
the  last  word  in  this  frame.  If  no  unreturned  cross-domain  calls  exist, 
then  DASDR. SEGNO  and  DASDR. W0RDN01  will  specify  the  beginning  location 
for  the  DAS  of  the  process,  and  DASDR. W0RDN02  will  equal  DASDR. W0RDN01. 

As  can  be  seen  by  comparing  Figures  3-5  and  3-6,  the  creation  of  a 

new  DAS  frame  by  the  CALL  instruction  in  the  case  >'f  a  cross-domain  call 

is  quite  straightforward.  PRa  locates  the  argument  list  to  be  used  as 

the  information  source  and  (DASDRv. SEGNO, DASDR. W0RDN02)  is  the  two-part 

address  for  the  beginning  of  the  new  frame.  While  creating  a  new  DAS 

frame  the  processor  validates  all  references  to  the  argument  list 

relative  to  u.w  static  access  capabilities  of  the  domain  from  which  the 
* 

call  is  being  made  and  validates  all  references  to  the  DAS  relative  to 
the  static  access  capabilities  of  domain  0. 


According  to  the  normal  pattern  of  operation  described  earlier,  an 
executing  procedure  has  static  access  t.r  :ts  activation  record  and  to 
any  argument  lists  it  creates  for  interprocedure  calls.  To  simplify 
the  processor  description,  the  processor  protection  mechanisms  are  de¬ 
signed  to  accomodate  only  this  normal  pattern  of  operation.  The 
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Figure  3-6:  A  dynamic  access  stack  frame  for  a  single  cross-domain 
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The  first  capability  in  the  DAS  frame  is  the  return  gate  capability 
This  contains  the  return  pointer  and  the  activation  record  pointer  from 
words  1  and  2  of  the  argument  list.  It  also  contains  the  number  of  the 
domain  to  which  the  return  should  be  made  (DOMAIN),  i.e.,  ti«e  domain  of 
execution  at  the  time  the  call  is  made.  The  final  item  in  this  capa¬ 
bility  (LASTFRAME)  is  the  word  number  of  the  beginning  of  the  previous 
DAS  frame,  as  found  in  DASDR.W0RDN01. 

Following  the  return  gate  capability  in  the  DAS  frame  ar«  , he 
capabilities  allowing  read  and  write  access  to  the  various  argume..  _s. 
Each  two-word  argument  entry  in  the  argument  list  generates  a  two-word 
capability  at  the  matching  location  in  the  DAS  frame.  The  capability 
gives  procedures  executing  in  the  called  domain  access  *  ->  the  subsegment 
specified  by  the  argument  entry.  The  first  word  of  the  capability  is  a 
pointer  to  the  beginning  cf  the  argument,  copied  from  che  -igument  entry 
The  second  word  contains  the  read  and  write  permission  flags  from  the 
argument  entry.  The  END  field  in  the  second  word  is  the  word  number  of 
the  last  word  of  the  argument,  derived  by  adding  the  size  from  the 
.rgument  entry  co  the  word  number  i.i  the  argument  pointer  and  subtract¬ 
ing  one.  (The  ending  word  number  is  easier  to  interpret  than  the  size 

footnoted  statement  in  the  text  ab  >-=  is  the  first  of  several  places 
where  this  decision  is  apparent  in  <.  e  processor  design.  If  some  pro¬ 
cedure  chooses  not  Lo  conform  tc  these  standards  and  instead  creates  an 
activation  record  or  an  argument  list  to  which  it  has  dynamic  access, 
however,  the  protection  mechanisms  will  not  be  circumvented.  But  such 
unconventional  behavior  is  not  fully  supported  and  that  procedure  will 
not  be  able  to  make  cross-domain  calls.  While  it  is  hard  to  imagine 
the  circumstances  under  which  a  procedure  would  find  creating  a  dynam¬ 
ically  accessible  activation  record  or  argument  list  to  be  useful,  the 
processor  could  be  extended  to  fully  support  such. 
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when  matching  references  to  the  dynamic  access  capabilities.) 

The  meaning  of  the  SOURCE  field  in  the  second  word  of  the  capability 
is  a  little  harder  to  explain.  Recall  from  Chapter  2  that  dynamic  access 
capabilities  must  be  constrained  to  give  no  more  access  than  is  r.vail- 
able  in  the  calling  domain.  In  order  to  enforce  this  constraint,  before 
making  the  corresponding  dynamic  access  capability  the  processor  must 
verify  that  the  argument  specified  by  an  argument  entry  is  in  fact 
accessible  from  the  calling  domain  in  the  manner  indicated.  There  are 
tvo  ways  for  the  calling  procedure  to  have  access  to  the  argument: 
access  can  be  allowed  by  virtue  of  a  static  access  capability  in  the 
calling  domain  or  by  virtue  of  a  dynamic  access  capability  in  the  calling 
domain.  The  tag  portion  of  the  pointer  to  the  beginning  of  the  argument 
in  the  argument  entry  specifies  the  opinion  of  the  calling  procedure  as 
to  which  is  the  case.  When  the  tag  is  on.  specifying  dynamic  access, 
the  calling  procedure  is  indicating  its  intention  of  passing-on  all  or 
part  of  an  argument  from  the  earlier  cross-domain  call  that  began 
execution  in  the  calling  domain.  When  the  tag  is  off,  specifying  static 
access,  the  calling  procedure  is  indicating  that  the  argument  originates 
in  the  calling  domain. 

If  the  argument  pointer  tag  is  off,  then  the  calling  domain  is  the 
source  of  the  argument  and  the  processor  must  verify  that  the  subsegment 
specified  in  the  argument  entry  is  accessible  tc  the  calling  domain  by 
virtue  of  its  static  access  capabilities.  The  obvious  way  to  perform 
this  verification  is  to  reference  the  DSE  for  the  containing  segment  and 
check  that  the  appropriate  read  and/or  write  permission  flags  are  or. 

If  the  check  succeeds  the  dynamic  access  capability  can  be  created. 


Wich  this  method  the  fact  that  the  dynamic  access  capability  exists  is 
proof  that  the  calling  domain  includes  the  required  static  access 
capability.  A  very  important  disadvantage  of  this  method  is  that  it 
makes  it  hard  to  change  (or  revoke)  the  st.i  .*  ^cess  from  various 
domains  of  a  process  to  a  segment.  Not  only  do  permission  bits  in  the 
corresponding  DSE  need  co  be  changed  (which  is  easy  to  do),  but  all 
dynamic  access  capabilities  in  the  DAS  giving  access  to  pieces  of  the 
segment  must  be  found  and  changed  (which  is  hard  to  do).  To  get  around 
this  problem,  no  check  of  static  access  is  mac'.e  when  the  dynamic  access 
capability  is  created.  Instead,  the  number  of  the  calling  domain  is 


simply  recorded  in  the  SOURCE  field  of  the  dynamic  access  capability  as 
the  source  of  the  capability.  The  static  access  of  the  calling  domain 
will  be  verified  each  time  the  dynamic  access  capability  is  used  to 
validate  a  reference  from  the  called  domain.  In  other  words,  if  a  parti¬ 
cular  reference  by  a  procedure  executing  in  the  called  domain  appears  to 
be  allowed  because  it  matches  the  dynamic  access  capability,  then  the 
reference  is  also  checked  against  the  static  access  capabilities  in  the 
domain  ind-'cated  by  the  SOURCE  field.  As  a  "esult,  the  dynamic  access 
capability  can  give  no  more  access  than  is  available  from  the  static 
access  capabilities  in  the  calling  domain. 
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specified  in  the  argument  entry  is  accessible  to  the  calling  domain  by 
virtue  of  its  dynamic  access  capabilities.  These  are  the  capabilities 
in  the  DAS  frame  just  above  the  new  frame  being  created.  This  previous 
frame  is  searched  for  a  capability  allowing  the  subsegment  to  be  read 
and/or  written,  as  required,  and  if  one  is  found  then  the  capability 
for  the  argument  in  the  new  DAS  frame  can  be  created.  The  SOURCE  field 
in  the  new  capability  is  set  with  the  value  from  the  SOURCE  field  in  the 
matching  capability  from  the  previous  DAS  frame.  As  a  result,  when  an 
argument  (or  successively  smaller  pieces  of  an  argument)  is  cascaded 
through  a  chain  of  cross-domain  calls,  the  identity  of  the  source 
domain  is  propagated  to  the  corresponding  capability  in  each  consecutive 
DAS  frame. 

In  summary  then,  the  SOURCE  field  in  a  dynamic  access  capability 
indicates  the  domain  at  the  head  of  the  chain  of  cross-domain  calls 
down  which  perraisj  ' ‘  i  to  reference  the  corresponding  subsegment  has 
been  passed.  The  existence  of  a  dynamic  access  capability  in  the  DAS 
frame  for  some  particular  cross-domain  call  is  proof  that  permission  to 
read  and/or  write  the  specified  subsegment  was  passed  along  by  «'cch 
cross-domain  call  in  the  chain  from  the  specified  source  domain  to  the 
called  domain.  Any  time  a  dynamic  access  capability  is  actually  used  to 
validate  a  reference,  the  reference  is  also  checked  against  the  static 
access  capabilities  in  the  source  domain  for  that  capability. 

Looking  back  for  a  moment  at  the  return  gate  capability,  it  is  now 
apparent  that  the  DOMAIN  field  in  this  capability  can  be  interpreted  as 
indicating  its  source  domain  (which  is  always  the  calling  domain)  as 
well  as  the  domain  to  which  the  return  is  to  be  made.  It  follows  that, 
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on  a  cross-domain  return,  after  verifying  that  PRs  contains  the  activa¬ 
tion  record  pointer  recorded  in  the  return  gate  capability  and  that  the 
return  is  to  the  return  location  recorded  in  the  return  gate  capability, 
a  check  must  be  made  to  assure  that  the  return  point  is  in  a  segment 
which  by  static  access  capability  is  executable  in  the  calling  domain. 

After  creating  dynamic  access  capabilities  for  all  the  arguments, 
a  final  capability  is  created  in  the  new  DAS  frame  giving  read  access 
to  the  subsegment  containing  the  argument  list  itself.  (The  called 
procedure  needs  to  be  able  to  read  the  argument  list  to  find  the  argu¬ 
ments.)  The  pointer  in  this  capability  comes  from  PRa  and  the  END  field 
value  is  calculated  from  the  argument  list  header.  The  source  domain  of 
this  capability  is  the  calling  domain. 

Creation  of  the  new  DAS  frame  is  completed  by  updating  DASDR  to 
locate  the  new  frame,  i.e.,  DASDR. W0RDN01  is  set  from  DASDR. W0RDN02  and 
then  DASDR. W0RDN02  is  set  to  indicate  the  word  one  past  the  end  of  the 
new  frame. 

Destroying  the  DAS  frame  on  a  cross-domain  return  is  done  by 
setting  DASDR. W0PDN02  from  DASDR. W0RDN01 .  arid  setting  1 ASDR.WORDNOl 
from  the  LASTFRAME  field  of  the  return  gate  capability  in  the  destroyed 
frame. 

Before  leaving  this  discussion  of  dynamic  access  capabilities,  the 
algorithm  used  to  match  a  reference  against  the  dynamic  access  capa¬ 
bilities  of  a  domain  nerds  to  be  stated  more  precisely.  Assume  a  read 
reference  to  location  (s.d)  is  to  be  validated  with  respect  to  the 
dynamic  access  capabilities  of  the  domain  ot  execution.  The  matching 
algorithm  is  to  perform  a  linear  search  of  the  most  recent  DAS  frame, 
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i.e.,  the  frame  located  by  DASDR,  starting  with  word  3,  looking  for  a 
capability  that  meets  all  of  the  following  conditions: 

1.  read  permission  flag  in  the  capability  is  on, 

2.  segment  number  from  the  pointer  in  the  capability  is  j>, 

3.  word  number  from  the  pointer  in  the  capability  is  less  than  or 
equal  to  d, 

4.  END  field  in  capability  is  greater  than  or  equal  to  jd. 

The  first  capability  that  matches  stops  the  search.  The  reference  is 
allowed  only  if  it  also  passes  the  check  against  the  static  access 
capabilities  of  the  indicated  source  domain.  If  no  match  occurs,  or  the 
static  access  check  fails,  then  the  reference  is  not  allowed.  A  write 
reference  is  handled  in  the  analogous  way.  The  linear  search  required 
can  be  eliminated  in  the  case  of  multiple  references  to  the  same  argu¬ 
ment  by  the  addition  to  the  processor  of  a  small,  fast  associative 
memory  for  the  most  recently  used  dynamic  access  capabilities.  Such 
an  associative  memory  will  be  described  in  more  detail  later. 


Propagation  of  Tags 

When  a  cross-domain  call  occurs  the  tag  in  PR£  is  set  on.  The 
purpose  of  this  action  is  to  cause  all  pointers  generated  in  the  called 
domain  that  are  related  to  cross-domain  arguments  to  have  tags  that  are 
on.  Then  references  through  these  pointers  will  be  validated  relative 


to  the  dynamic  access  capabilities  added  to  the  called  domain  by  the 
cross-domain  call,  and  not  relative  to  the  static  access  capabilities  of 
the  called  domain.  The  propagation  of  the  tag  from  PRji  to  other  pointers 
related  to  cross-domain  arguments  is  caused  by  the  effective  pointer 
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generation  algorithm  presented  earlier.  This  algorithm  guarantees  that 
any  pointer  generated  from  a  pointer  whose  tag  is  on  will  also  have  its 
tag  on.  If  applied  properly  by  procedures  executing  in  the  called 
domain,  the  algorithm  guarantees  that  all  pointers  generated  from  PIte, 
and  pointers  generated  from  these  pointers,  etc.,  will  have  their  tags 
set  on. 

An  example  will  illustrate  the  method  of  tag  propagation.  Imagine 
that  a  subsegment  containing  a  threaded  list  of  variable-sized  blocks 
is  passed  as  argument  0  on  a  cross-domain  call.  The  argument  entry 
and  the  corresponding  dynamic  access  capability  will  contain  a  pointer 
to  the  beginning  of  this  subsegment  and  specify  its  length.  Each  block 
in  the  subsegment  contains  ir.  word  1  the  size  of  the  block  and  in  word  0 
a  pointer  to  the  next  block  in  the  threaded  list.  The  first  block  on 
the  list  is  known  to  begin  at  word  0  of  the  subsegnu  t.  (It  is  quite 
possible  to  define  and  manipulate  a  data  structure  like  this  in  PL/I 
using  based  structures.)  This  data  structure  originated  in  the  calling 
domain,  and  therefore  the  pointer  in  the  argument  entry  as  well  as  all 
the  list  pointers  in  the  data  structure  itself  have  tags  that  are  off. 
When  the  cross-domain  call  occurs  a  dynamic  access  capability  f*  read 
and  write  the  subsegment  is  created  and  the  tag  in  PRa  is  set  on. 

Now  consider  the  machine  language  implementation  of  some  operations 

the  called  procedure  might  perform  on  this  argument.  Execution  of  the 

following  instruction  sequence  by  the  called  procedure  will  generate 

tH 

in  PRn  a  pointer  to  the  100  block  in  the  list: 


'3  imw?Ii5W?Rn  1 1 


gated  all  through  the  instruction  sequence  in  PRn.  (Refer  to  the  effc 
tive  pointer  generation  algorithm  in  Figure  3-3  to  see  that  this  really 
works.)  All  during  the  instruction  sequence  the  references  to  the  point¬ 
ers  in  the  blocks  as  indirect  addresses  will  be  validated  with  respect 
to  the  dynamic  access  capabilities  of  the  called  domain,  and  specifi¬ 
cally  will  match  the  capability  giving  access  to  the  whole  subsegment 


that  is  argument  0. 

Now  imagine  that  the  called  procedure,  after  laboriously  gei  -  ting 
th 

this  pointer  to  the  100  block  in  the  list,  wants  to  save  it  in  a 
temporary  storage  location  in  the  current  activation  record.  The 
instruction: 

SPPn  PRsttemp 

does  the  trick.  Note  that  this  write  reference  to  a  word  of  the  activa¬ 
tion  record  will  be  validated  with  respect  to  the  static  access  capa¬ 
bilities  of  the  called  domain,  since  the  tag  in  PRs  is  off.  However, 
the  stored  pointer  will  have  its  tag  on.  Later,  the  tracing  of  the  list 
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There  is  a  way  to  break  the  chain  of  propagation  of  the  tag  from 


PRai.  If  the  called  procedure  now  transfers  the  list  pointer  contained 
.th 


in  the  150  block  to  another  temporary  storage  location  in  the  activa¬ 
tion  record  using  the  code  sequence: 

LOAD  PRntO 
STORE  PRs t temp2 

then  the  tag  in  the  stored  pointer  will  be  off.  The  propagation  of  the 


tag  from  PRa  is  broken  because  LOAD/STORE  generates  a  direct  copy  of  the 

th 


pointer  from  the  150  block  whose  tag  is  also  off.  The  alternative 
sequence: 

EPPn  PRnfO,* 

SPPn  PRsttemp2 

results  in  a  stored  pointer  whose  tag  is  on.  When  copying  a  pointer, 
EPPn/SPPn  must  be  used  rather  than  LOAD/STORE  to  make  sure  the  relation 
of  a  pointer  to  a  cross-domain  argument  is  not  lost.  By  violating  this 
rule,  however,  a  procedure  can  compromise  only  the  integrity  of  its 
own  domain.  It  cannot  gain  unauthorized  access  to  information.  Only 
self-protection  is  at  stake. 


Now  imagine  that  the  called  procedure  wishes  to  load  into  the 

.th 


accumulator  the  size  from  word  1  of  the  100  block,  the  block  whose 
address  was  stored  earlier  at  "PRs t temp".  The  instruction  sequence: 

EPPn  PRa T  temp , * 

LOAD  PRnt 1 

does  the  trick,  and  validates  the  read  reference  -ord  1  of  the  100 
block  with  respect  to  the  dynamic  access  capabilities  of  the  domain, 
since  the  tag  in  PRn  will  be  on. 


th 
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As  the  final  example,  imagine  that  the  called  procedure  in  turn 


generates  another  cross-domain  call  and  passes  as  the  zeroth  argument 
.tfe 


this  100  *  block  from  the  list.  After  saving  the  current  value  of  PIte 
somewhere  in  its  activation  record,  allocating  space  for  the  required 
new  argument  list,  and  resetting  PIte  to  point  at  this  new  argument  list 
area,  the  argument  pointer  in  the  zeroth  argument  entry  would  be  created 
with: 

EPPn  PRa t  temp, * 

SPPn  PRat3 

Note  that  this  argument-  pointer  will  have  its  tag  set  on,  correctly 
indicating  to  the  processor  when  it  constructs  the  required  new  DAS 
frame  that  the  argument  comes  from  a  previous  cross-domain  call. 

This  is  a  good  place  to  reemphasize  why  it  is  important  that  pro¬ 
cedures  executing  in  some  domain  be  able  to  identify  those  pointers 
that  are  related  to  incoming  cross-domain  arguments  and  validate  all 
references  through  such  pointers  against  the  dynamic  access  capabilities 
currently  in  the  domain,  rather  than  against  the  static  access  capa¬ 
bilities  of  the  domain.  As  indicated  in  Chapter  2,  the  essential  reason 
is  that  all  pointers  related  to  cross-domain  arguments  are  derived  from 
pointers  provided  by  the  calling  domain.  The  pointers  in  PRa,  in  argu¬ 
ment  list  entries,  and  in  arguments  themselves,  e.g.,  as  in  the  1  nked 
list  example  given  above,  are  all  arbitrary  bit  patterns  set  by  pro¬ 
cedures  executing  in  the  calling  domain  or  some  other  domain  further 
back  along  the  chain  of  unreturned  cross-domain  calls  for  the  process. 
When  the  cross-domain  call  occurred,  the  processor  constructed  the 
dynamic  access  capabilities  in  such  a  way  that  they  are  guaranteed  to 
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pass-cn  to  the  called  domain  no  more  access  than  is  dynamically  or 

statically  available  from  the  calling  domain.  The  processor  even 

arranged  things  in  such  a  way  that  if  the  static  access  capability  which 

is  the  original  source  of  permission  in  a  dynamic  access  capability 

changes,  then  the  change  immediately  propagates  to  the  dynamic  access 

capability.  The  processor,  however,  did  not  and  could  not  check  all  of 

the  pointers  that  can  be  generated  starting  with  the  pointer  in  PRa. 

There  is  no  guarantee  that,  say,  in  the  linked  list  example  given  above, 

th 

the  list  pointer  in  the  99  block  will  not  by  malice  or  error  point  at 

\ 

a  critical  data  base  in  the  called  domain  that  is  not  accessible  from 

th 

the  calling  domain,  rather  than  point  at  the  100  block  in  the  subseg¬ 
ment  that  is  the  cross-domain  argument.  When  the  called  procedure  makes 

a  write  reference  via  this  pointer,  it  d<  °s  so  with  the  intention  of 

th 

writing  something  in  the  100  '  block  of  the  argument.  If  the  pointer 
locates  a  portion  of  the  critical  data  base,  then  the  called  procedure 
wants  the  write  reference  to  fail.  The  propagation  of  the  tag  that  is 
on  from  PRa  guarantees  that  the  write  will  fail,  for  this  tag  causes 
validation  relative  to  the  dynamic  access  capabilities  created  by  the 
cross-domain  call,  and  these  capabilities  will  not  provide  write  access 
to  the  critical  data  base.  Without  the  propagated  tag  the  write  would 
succeed,  for  the  static  access  capabilities  of  the  called  domain  do 
allow  write  access  to  the  critical  data  base. 

Recall  that  a  tag  that  is  on  in  the  effective  pointer  generated  by 
a  RETURN  instruction  is  what  triggers  a  cross-domain  return.  This  tag 
propagates  from  the  tag  in  PRa  in  the  same  way  chav,  the  tags  in  argu¬ 
ment-related  pointers  are  propagated  from  the  tag  in  PRa.  To  see  this, 
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consider  the  last  two  instructions  of  the  standard  return  sequence  again: 

EPPs  PRat2j  * 

RETURN  PRatl,* 

It  is  cleat  that  if  the  tag  in  PRa  is  on,  as  it  would  be  when  the 
corresponding  call  is  cross-domain,  then  the  effective  pointers  generated 
by  both  instructions  will  have  tags  tnat  are  on.  In  the  case  of  the 
RETURN  instruction  this  propagated  tag  triggers  the  cross-domain  return. 
In  the  case  of  the  EPPj;  instruction  it  generates  an  interesting  problem. 
The  purpose  of  the  EPPj>  instruction  is  to  restore  to  PR£  the  activation 
record  pointer  of  the  calling  procedure.  This  pointer,  as  it  was  re¬ 
corded  by  the  calling  procedure  in  the  return  block  of  the  argument  list, 
had  its  tag  set  off.  (An  executing  procedure  always  has  static  access 
to  its  activation  record.)  Yet  the  EPP^  instruction  restores  this 
activation  record  pointer  to  PRs  with  its  tag  set  on.  To  correct  this 
problem,  part  of  the  special  action  of  the  RETURN  instruction  on  a  cross¬ 
domain  return  is  to  set  the  tag  in  PR^  off.  Thus,  when  the  calling 
procedure  receives  control  following  the  cross-domain  return,  PRjs 
properly  contains  the  same  activation  record  pointer  it  had  before  the 
cross-domain  call  occurred,  even  though  the  EPP^  instruction  restored 
the  tag  incorrectly. 

The  problem  encountered  here  in  restoring  PRj>  on  a  cross -domain 
return  foreshadows  a  general  problem  which  will  be  considered  later. 

On  a  cross-domain  call,  whenever  the  called  procedure  generates  a 
pointer  to  be  used  by  the  calling  procedure  after  the  return  occurs,  care 
must  be  taken  to  set  the  tag  properly  for  use  by  the  calling  procedure. 
For  stored  pointers  a  simple  addition  to  the  SPPri  instruction,  the 
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instruction  used  to  create  stored  pointers,  can  detect  these  cases 
and  automatically  generate  the  correct  tag.  This  algorithm  will  be 
presented  in  detail  later  in  the  chapter.  The  case  of  a  pointer  being 
communicated  through  a  PR,  however,  cannot  be  detected  by  a  similar 
algorithm  added  to  the  EPPn  instruction.  The  only  instance  of  this  ^ 

second  case,  however,  is  the  communication  of  an  activation  record 
pointer  in  PRj;.  A.  seen  in  the  previous  paragraph,  the  tag  in  PRs^  can 
be  adjusted  easily  when  the  cross- domain  return  occurs. 

Multibit  Tags 

Exploring  a  little  further  the  example  of  the  argument  that  is  a 

subsegment  containi*  c  a  linked  list  points  out  a  flaw  in  the  processor 

design  as  described  so  far.  Consider  the  case  of  a  cross-domain  call 

from,  say,  domain  7  to  domain  2  followed  by  a  cross-domain  call  from 

domain  2  to  domain  4,  as  illustrated  in  Figure  3-7.  The  subsegment 

containing  the  linked  list  is  passed  as  a  read/write  argument  on  the 

tH 

first  cross-domain  call.  The  pointer  in  the  99  block  of  the  list 
maliciously  has  been  set  by  procedures  executing  in  domain  7  to  point 
at  some  data  base  in  domain  2,  a  data  base  not  accessible  from  domain  7. 

As  seen  above,  procedures  executing  in  domain  2  cannot  be  tricked  by  this 
bad  pointer  because  the  tag  propagated  from  PRu  will  cause  attempted 
read  and  write  references  through  this  had  pointer  to  fail.  Suppose 
that  instead  of  directly  referencing  this  argument  provided  by  domain  7, 
however,  the  called  procedure  in  turn  passes  the  subsegment  as  a 
read/write  argument,  of  the  cross-do. tain  call  from  domain  2  to  domain  4. 
Another  read/write  argument  of  this  second  call  happens  to  ba  that  data 
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data  base 
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J  linked  list 
]  argument 


Figure  3-7:  Two  consecutive  cross-domain  calls  with  one  argument 
cascaded  through  both. 
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th 

base  pointed  at  by  the  bad  address  in  the  99  block  of  the  linked  list 
in  the  first  argument. 

Now  consider  the  procedure  called  by  this  second  cross-domain  call. 
Executing  in  domain  4,  it  locates  the  99^  block  ir.  the  linked  list  in 
the  manner  described  earlier  and  then  uses  the  contained  pointer  to  make 
a  write  reference  with  the  intention  of  writing  in  the  100  “  block. 
Because  of  the  bad  pointer,  however,  the  write  is  actually  to  the  data 
base  that  happens  to  be  the  other  cross-domain  argument  provided  from 
domain  2.  Of  course,  the  tag  of  the  pointer  used  to  make  this  reference 
will  be  on  as  before,  and  the  reference  will  be  validated  with  respect 
to  the  dynamic  access  capabilities  associated  with  the  second  cross¬ 
domain  call.  In  this  case  the  reference  will  succeed  because  it  is 
to  a  valid  writable  cross-domain  argument  of  that  call  and  thus  a 
matching  dynamic  access  capability  will  be  found. 

What  really  has  happened  here?  In  a  sense,  the  procedure  executing 
in  domain  4  has  not  done  anything  wrong.  It  has  permission  to  write 
in  the  data  base  argument  in  which  it  wrote.  But  this  procedure  did 
make  a  mistake,  writing  into  domain  2's  data  base  the  data  it  was  in¬ 
tending  to  put  in  the  100ttl  block  of  the  linked  list  in  the  other  argu¬ 
ment.  The  important  thing  about  this  mistake  is  that  it  was  caused  by 
procedures  executing  in  a  third  domain.  The  problem  illustrated  by  this 
example  is  particularly  insidious  in  cases  where  the  domain  that  receives 
the  second  cross-domain  call  encapsulates  part  of  the  supervisor  and 
thus  is  trusted  by  the  domain  that  made  the  second  call.  In  this  cir¬ 
cumstance  the  procedure  that  made  the  second  cross-domain  call  has  no 
reason  to  check  after  the  return  has  occurred  that  the  trusted  supervisor 
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has  written  reasonable  values  into  the  output  arguments  and  therefore 
may  not  notice  the  mistake  before  it  leads  to  a  disastrous  error.  It 
is  possible  to  construct  many  examples  like  this  involving  two  or  more 
cross-domain  calls. 

An  analysis  of  why  in  the  example  given  a  procedure  executing  in 
domain  7  could  cause  a  procedure  executing  in  domain  4  to  incorrectly 
alter  data  encapsulated  in  domain  2  reveals  the  general  flaw  in  the 
protection  mechanisms  of  the  processor  as  presented  so  far.  The  reason 
the  problem  occurred  is  that  a  reference  through  a  pointer  generated 
from  a  cross-domain  argument  whose  source  was  domain  7  was  allowed  be¬ 
cause  it  matched  a  dynamic  access  capability  whose  source  was  domain  2. 
To  prevent  the  general  class  of  problem  represented  by  this  example  from 
occurring,  the  processor  must  be  altered  so  that  a  reference  through  a 
pointer  generated  from  a  cross-domain  argument  whose  source  is  domain 
n  will  be  allowed  only  if  it  matches  a  dynamic  access  capability  whose 
source  is  domain  n.  This  change  requires  expanding  the  tag  portion  of 
pointers  to  specify  the  source  domain  of  the  cross-domain  argument  from 
which  the  pointer  was  derived,  if  in  fact  the  pointer  was  derived  from 
a  cross-domain  argument. 

The  obvious  value  to  record  in  a  tag  indicating  dynamic  access  is 
the  number  of  the  source  domain  associated  with  a  pointer.  This  number 
is  then  matched  to  the  SOURCE  field  in  dynamic  access  capabilities. 

There  are  two  problems  with  this  approach.  First,  when  generating  an 
effective  pointer  using  the  expanded  tag.  the  processor  must  be  able  to 
determine  =. _ch  of  two  tag  values  indicating  dynamic  access  corresponds 
to  a  cross-domain  call  that  is  further  back  ir.  the  chain  of  unreturned 
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cross-domain  calls  for  the  process.  It  is  hard  to  make  this  determina¬ 
tion  quickly  from  domain  numbers  alone.  The  second  problem  is  more  im¬ 
portant.  To  be  consistent  with  programming  generality  it  must  be 
possible  for  the  chain  of  unretumed  cross-domain  calls  in  a  process  to 
include  recursive  invocations  of  domains.  When  recursive  invocations  of 
domains  occur  the  domain  number  by  itself  does  not  specify  which  invoca¬ 
tion  of  a  particular  domain  originally  passed  the  argument  from  which  a 
pointer  was  derived,  and  this  distinction  can  be  important.  When  the 
possibility  of  recursive  invocations  of  domains  is  considered,  it  becomes 
apparent  that  the  source  of  a  cross-domain  argument  or  a  dynamic  access 
capability  is  not  just  a  domain  but  a  domain  invocation.  What  needs  to 
be  recorded  in  dynamic  access  tags  and  in  dynamic  access  capabilities  is 
the  identity  of  a  domain  invocation,  not  just  the  number  of  a  domain. 

The  dynamic  access  stack  (DAS)  of  a  process  provides  a  convenient 
numbering  for  the  domain  invocations  that  exist  at  any  given  time.  Each 
time  a  cross-domain  call  occurs  a  new  DAS  frame  is  created.  The  number 
of  the  frame  can  be  used  as  an  identifier  for  the  domain  invocation  from 
which  the  cross-domain  call  came  that  generated  the  frame.  It  is  these 
domain  invocation  numbers  that  are  recorded  in  dynamic  access  capabilities 
and  in  tags  specifying  dynamic  access.  If  the  first  DAS  frame  is  given 
the  number  one,  then  the  number  zero  can  never  identify  a  domain  invoca¬ 
tion.  Thus,  the  tag  value  zero  can  be  used  to  specify  that  reference 
through  a  pointer  be  validated  with  respect  to  static  access  capabilities. 
A  non-zero  tag  specifies  validation  with  respect  to  dynamic  access  capa¬ 
bilities  and  the  non-zero  value  identifies  the  source  domain  invocation. 

Certain  aspects  of  the  processor  are  now  redescribed  to  incorporate 
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the  expanded  tag  into  the  design.  The  length  chosen  for  the  tag  field 
determines  the  maximum  number  of  unreturned  cross-domain  calls  that  can 
exist  in  a  process.  A  five  bit  tag,  fixing  this  maximum  at  31,  is  con¬ 
sistent  with  the  choice  of  eight  as  the  number  of  domains  per  process 
that  the  processor  will  support.  To  provide  an  easy  means  for  generating 
DAS  frame  numbers  and  domain  invocation  numbers,  a  cross-domain  call 
count  field  is  added  to  the  DAS  definition  register  (DASDR.XDCC)  as  illus¬ 
trated  in  Figure  3-8.  If  no  unreturned  cross-domain  calls  exist,  and 
thus  no  DAS  frame  exist,  then  DASDR.XDCC  =  0.  Each  time  a  cross-domain 
call  occurs  and  a  new  DAS  frame  is  created  DASDR.XDCC  is  incremented  by 
one.  (DASDR.XDCC  is  not  allowed  to  overflow.)  A  cross-domain  return 
causes  it  to  be  decremented  by  one.  At  any  given  time,  then,  DASDR.XDCC 
contains  the  number  of  the  most  recent  DAS  frame.  This  value  is  also  the 
number  of  the  domain  invocation  from  which  the  cross-domain  call  came  that 
started  execution  in  the  current  domain  of  execution.  In  the  state  shown 
in  Figure  3-8,  for  example,  three  unretumed  cross-domain  calls  exist. 

It  is  clear  that  at  any  given  time  only  tag  values  less  than  or  equal  to 
DASDR.XDCC  mean  anything. 

The  modified  effective  pointer  generation  algorithm  is  shown  in 
Figure  3-9.  It  loo^s  fairly  complex  but  has  a  simple  effect.  If  only 
tags  of  zero  are  encountered  during  effective  pointer  generation,  then 
the  final  effective  pointer  has  a  tag  of  zero,  indicating  that  the  refer¬ 
ence  through  the  pointer  will  be  validated  relative  to  the  static  access 
capabilities  of  the  domain  of  execution.  If  only  one  non-zero  tag  is 
encountered  (in  the  indicated  PR  or  indirect  address),  then  assuming  the 
value  of  this  tag  is  meaningful,  i.e.,  £  DASDR.XDCC,  the  final  effective 
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Figure  3-8:  Dynamic  access  stack  containing  frames  for  three 
unreturned  cross-domain  calls. 
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pointer  has  the  same  non-zero  tag  value,  indicating  that  the  reference 
through  the  pointer  will  be  validated  relative  to  the  dynamic  access 
capabilities  currently  in  the  domain  of  execution.  The  non-zero  tag 
value  is  the  source  domain  invocation  number  to  be  used  in  finding  a 
matching  dynamic  access  capability.  The  interesting  case  is  when  both 
PR-relative  and  indirect  addressing  are  indicated,  and  both  the  PR  and 
the  indirect  address  have  non- zero  tags.  Assuming  no  error  is  generated 
because  the  PR  tag  is  greater  than  DASDR.XDCC,  the  indirect  address  tag 
is  checked  to  make  certain  it  is  smaller  than  the  PR  tag,  and  if  it  is 
then  the  indirect  address  tag  provides  the  value  for  the  tag  in  the  final 
effective  pointer.  That  the  indirect  address  tag  be  smaller  than  the  PR 
tag  is  important.  A  non-zero  PR  tag  with  a  value  J:  indicates  that  the 
indirect  address  located  by  the  PR  is  in  the  argument  list  or  is  in  an 
argument  of  the  J:*'*1  unretumed  cross-domain  call.  From  the  vantage  point 
of  domain  invocation  Jt  (the  domain  invocation  from  which  the  t1"*1  cross¬ 
domain  call  came),  only  tag  values  less  than  £  mean  anything.  When  the 
argument  list  was  created,  Jt-l  was  the  number  of  the  most  recent  DAS  frame. 
In  that  circumstance  a  pointer  with  a  tag  value  greater  than  or  equal  to 
J:  would  not  mean  anything.  Further,  if  the  effective  pointer  generation 
algorithm  accepted  a  tag  value  strictly  greater  than  t  from  the  indirect 
address  located  by  the  PR,  then  one  aspect  of  the  previously  described 
flaw  would  remain  uncorrected.  The  effective  pointer  formed  using  infor¬ 
mation  provided  by  domain  invocation  _t  would  specify  in  its  tag  a  domain 
invocation  number  greater  than  t^. 

Propagation  of  the  new  expanded  tag  is  by  essentially  the  same  means 
used  for  the  one  bit  tag.  When  a  cross-domain  call  occurs  the  processor 


sets  the  tag  in  PRa  with  the  incremented  value  of  DASDR.XBCC.  This  is 
the  number  of  the  domain  invocation  from  which  the  cross-domain  call  comes. 
F.r  example,  if  a  cross-domain  call  occurred  when  the  DAS  were  in  the  state 
illustrated  by  Figure  3-8,  then  PR^.TAG  would  be  set  to  four.  Correct  use 
of  tl  •  effective  pointer  generation  algorithm  by  procedures  executing  in 
the  called  domain  guarantees  propagation  of  this  tag  (and  smaller  non-zero 
tags  if  encountered)  to  all  pointers  derived  from  cross-domain  arguments. 

The  purpose  of  the  expanded  tags,  of  course,  is  to  provide  an  addi- 
•  tonal  parametr-*  to  use  when  matching  a  reference  to  the  dynamic  access 
capabilities  currently  in  the  domain  of  execution.  Figure  3-10  presents 
the  detailed  format  of  a  dynamic  access  capability  giving  read  and/or 
write  access  to  a  subsegment.  The  TAG  field  in  the  first  word  is  used  to 
record  the  number  of  the  domain  -'avocation  that  is  the  source  of  the  capa¬ 
bility.  The  SOURCE  field  in  the  second  word  is  the  domain  number  associa¬ 
ted  with  the  source  domain  invocation.  The  TAG  field  provides  the  value 
to  be  used  when  matching  a  reference  through  a  pointer  to  the  dynamic 
access  capabilities  currently  in  the  domain.  Once  the  dynamic  access 
capability  that  matches  a  reference  has  been  seVcted,  the  contained 
SOURCE  field  specifies  which  domain's  static  access  capabilities  must  also 
allow  the  reference,  as  before. 

Recall  that  a  dynamic  access  capability  to  read  and/or  write  a  sub- 
segment  is  created  for  each  argument  entry  in  the  argument  list  of  a 
cross-domain  call.  (One  is  also  created  to  allow  read  access  to  the 
argume"  ■;  list  itself.)  With  the  expanded  tag,  creation  of  the  dynamic 
access  capability  tor  an  argument  entry  is  still  done  pretty  much  as 
described  earlier  for  the  one  bit  tag.  There  are  two  cases.  If  the  tag 


in  the  argument  pointer  from  the  argument  entry  is  zero,  then  the  source 
of  the  argument  is  the  domain  invocation  from  which  the  cross-domain 
call  is  being  made.  In  this  case  the  SEGNO,  WORDNO,  END,  SOURCE,  R, 
and  W  fields  of  the  dynamic  access  capability  are  set  as  before.  The  TAG 
field  is  set  with  the  number  of  the  domain  invocation  from  which  the  call 
is  being  made.  (Adding  one  to  the  value  in  DASDR.XDCC  at  the  time  the 
new  capability  is  being  created  produces  this  number.)  In  the  second 
case  the  tag  in  the  argument  pointer  is  greater  than  zero,  indicating 
that  an  argument  (or  piece  of  an  argument)  whose  source  domain  invoca¬ 
tion  is  further  back  in  the  chain  of  unreturned  cross-domain  calls  in 
the  process  is  being  passed-on  by  this  cross-domain  call.  The  value  of 
the  tag  identifies  the  source  domain  invocation  for  the  argument.  In 
this  case  the  DAS  frame  previous  to  the  new  frame  being  created  is 
checked  for  a  matching  dynamic  access  capability  as  before.  (The  new 
matching  algorithm  presented  below  is  used.)  If  a  match  is  found  then 
the  new  dynamic  access  capability  can  be  created.  The  SEGNO,  WORDNO, 

END,  SOURCE,  R,  and  W  fields  are  set  as  before,  with  the  source  field 
value  being  copied  from  the  matching  capability.  The  TAG  field  in  the 
new  capability  is  set  from  the  tag  value  in  the  argument  pointer. 

The  dynamic  access  capability  allowing  references  to  the  argument 
list  is  also  constructed  as  before.  Its  TAG  field  is  set  with  the  num¬ 
ber  of  the  calling  domain  invocation,  for  the  source  of  this  capability 
is  always  the  calling  domain  invocation. 

The  result  of  the  way  the  TAG  fields  in  dynamic  access  capabilities 
are  set  is  that  each  capability  in  a  DAS  frame  correctly  indicates  the 


number  of  the  domain  invocation  that  is  its  source. 
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As  indicated,  the  value  of  the  TAG  field  in  a  dynamic  access  capa¬ 
bility  is  taken  into  account  when  matching  a  reference  to  the  dynamic 
access  capabilities  currently  in  the  domain  of  execution.  While  the 
only  difference  from  the  algorithm  presented  earlier  for  the  case  of  one 
bit  tags  is  the  additional  constraint  that  the  tag  from  the  pointer  must 
match  the  tag  in  a  capability,  the  entire  algorithm  for  matching  a 
reference  to  the  dynamic  access  capabilities  in  a  domain  is  presented 
again  for  the  sake  of  clarity.  Assume  a  read  reference  is  made  through 
a  pointer  containing  the  tag  where  t  >  0,  and  the  two-part  address 
(s,d).  The  reference  validation  algorithm  is  to  perform  a  linear  search 
of  the  most  recent  DAS  frame,  starting  with  word  3,  looking  for  a  capa¬ 
bility  that  meets  all  of  the  following  conditions: 

1.  Read  permission  flag  is  on. 

2.  TAG  field  contains  the  value  _t. 

3.  SEGNO  field  contains  the  value  js . 

4.  WORDNO  field  £  d  £  END  field. 

The  first  capability  that  matches  stops  the  search.  The  reference  is 
allowed  only  if  it  also  passes  the  check  against  the  static  access 
capabilities  of  the  domain  indicated  by  the  SOURCE  field.  Again,  vali¬ 
dation  of  a  write  reference  is  analogous. 

The  multibit  tag  does  not  change  the  way  the  return  gate  capability 
in  a  DAS  frame  is  matched.  At  any  given  time  only  one  cross-domain 
return  is  possible  in  a  process.  The  only  valid  non-zero  tag  which  can 
be  generated  in  the  effective  pointer  of  a  RETURN  instruction  is  the 
number  of  the  most  recent  DAS  frame.  The  pointer  in  PRs^  and  the  loca¬ 
tion  to  which  the  return  transfer  is  directed  must  match  the  two  pointers 
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in  the  single  return  gate  capability  in  that  frame  as  before. 

This  completes  all  but  one  of  the  changes  and  additions  to  the 
processor  necessary  to  incorporate  multibit  tags.  The  last  remaining 
addition  is  presented  in  the  next  section. 

Pointers  as  Arguments 

In  the  previous  two  sections  the  example  of  a  cross-domain  call 
argument  that  contained  stored  pointers,  i.e.,  indirect  words,  was  used. 
The  stored  pointers  provided  the  links  in  a  threaded  list  of  variable¬ 
sized  blocks.  There  are  several  subtleties  related  to  the  use  of  stored 
pointers  in  cioss-domain  arguments  that  must  be  explored. 

The  PL/I  language  includes  a  ,:pointer"  data  type.  In  a  machine 
such  as  that  being  described  here,  PL/I  pointer  variables  would  be  im¬ 
plemented  as  stored  pointers.  Thus,  an  argument  that  is  a  stored 

pointer  or  contains  stored  pointers  will  occur  whenever  a  PL/I  program 

I 

specifies  a  pointer  variable  itself  or  a  data  structure  containing 

i 

pointer  variables  as  an  argument  cf  an  interpruct-Gure  call. 

First  consider  the  use  of  a  pointer  variable  as  an  output  argument 
of  a  cross-domain  call.  For  simplicity  of  explanation  the  discussion 
is  presented  in  terms  of  an  output  argument  that  is  a  single  pointer 
variable,  although  the  ideas  presented  also  apply  to  output  arguments* 
which  are  larger  data  structures  containing  pointer  variables.  When 
the  cross-domain  call  occurs,  a  dynamic  access  capability  will  be 
created  allowing  procedures  executing  in  the  called  domain  to  write  into 
(and  read  from)  the  subsegment  containing  the  pointer  variable.  The 

! 

l  calling  procedure  must  recognize  that,  by  specifying  that  a  pointer 

! 

* 

| 

i 

l 

; 


107 


variable  is  an  output  argument,  the  called  procedure  in  another  domain 
is  given  the  ability  to  write  an  arbitrary  bit  pattern  into  this  pointer 
variable.  Thus,  after  the  return  has  occurred,  the  calling  procedure 
must  explicitly  check  that  a  reasonable  value  has  been  stored  in  this 
pointer  variable  before  it  is  used  to  make  a  reference  if  the  calling 
procedure  has  any  reason  to  mistrust  the  called  domain.  Normally,  when 
a  pointer  variable  output  argument  is  passed  on  a  cross-domain  call,  the 
called  domain  is  in  fact  trusted,  e.g.,  the  called  domain  may  encaosulate 
part  of  the  supervisor. 

The  interesting  question  about  pointer  variable  output  arguments 
for  cross-domain  calls  is  what  tag  value  will  be  placed  in  the  pointer. 

If  j:  is  the  domain  invocation  number  from  which  the  cross-domain  call 
is  made,  then  only  tag  values  strictly  less  than  t  »:ill  mean  anything 
to  the  calling  procedure.  Yet  to  the  called  procedure  in  the  next  higher 
numbered  domain  invocation,  a  tag  value  equal  to  certainly  means  some¬ 
thing  and  such  a  tag  value  might  be  stored  into  the  pointer  variable 
output  argument.  To  see  this  consider  the  following  example.  A  proce¬ 
dure  executing  in  domain  invocation  Jt  passes  as  an  input  argument  of  a 
cross-domain  call  some  data  structure  and  as  an  output  argument  a  pointer 
variable.  The  called  procedure  is  expected  to  locate  a  certain  item 
within  the  input  data  structure  and  return  a  pointer  to  this  item  in  the 
output  pointer  variable.  Because  pointer  variables  are  implemented  as 
stored  pointers,  i.e.,  indirect  addresses,  the  called  procedure  will 
write  the  value  into  the  pointer  variable  output  argument  using  the 
SPPn  instruction.  The  pointer  in  PRn  will  have  been  generated  by  apply¬ 
ing  the  effective  pointer  generation  algorithm  to  the  input  data 
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structure  in  various  ways,  and  thus  will  contain  the  tag  value  _t  propa¬ 
gated  from  PRa.  If  the  u  '  instruction  simply  stores  the  whole  pointer 
from  PRn  as  its  operand,  tnen  the  output  argument  pointer  variable  will 
also  have  a  tag  value  of  _t,  a  tag  value  that  means  nothing  to  the  calling 
procedure.  From  the  point  of  view  of  the  calling  procedure  and  the 
domain  invocation  in  which  it  is  executing,  the  correct  tag  is  zero, 
since  after  the  return  occurs  the  pointer  variable  will  be  used  to 
reference  the  data  structure  which  is  statically  accessible  in  that 
domain. 

To  solve  the  problem  illustrated  by  this  example,  and  others  like 
it,  the  SPPn  instruction  does  not  always  just  copy  PRn. TAG  into  the 
indirect  address  being  created.  It  is  able  to  detect  the  circumstances 
in  which  the  indirect  word  tag  should  be  set  to  zero,  and  will  set  it 
to  zero  in  these  cases.  The  algorithm  is  presented  in  Figure  3-11.  When 
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performing  the  SPPn  instruction  there  are  two  tag  values  to  consider: 
the  value  in  TPR.TAG  and  the  value  in  PRn. TAG.  In  the  simple  case  that 
TPR.TAG  is  zero,  then  the  operand  of  the  instruction  is  not  a  cross¬ 
domain  argument.  The  indirect  address  should  be  constructed  directly 
from  the  pointer  in  PRn,  tag  and  all.  Whatever  tag  may  have  propagated 
into  PRn  needs  to  be  preserved  in  the  stored  pointer. 

If  the  tag  in  TPR  is  non-zero,  then  the  operand  of  the  instruction 
is  a  cross-domain  output  argument  that  is  a  pointer  variable,  and  the 
potential  exists  for  the  sort  of  problem  to  occur  that  was  illustrated 
by  the  example  given  earlier.  Specific  examples  of  three  general  cases 
which  may  occur  are  illustrated  in  Figure  3-12.  In  all  cases  the  SPPn 
instruction  being  executed  is  writing  a  pointer  into  a  pointer  variable 
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Figure  3-11:  Algorithm  of  the  SPPn  instruction. 
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that  is  an  output  argument  of  a  cross-domain  call.  The  source  of  this 
argument  is  domain  invocation  2.  Thus,  the  tag  in  TPR  is  two. 

In  case  1  the  pointer  in  PRn  was  constructed  from  scratch  or  de¬ 
rived  from  pointers  not  related  to  cross-domain  arguments,  and  therefore 
has  a  tag  of  zero.  For  example,  the  domain  of  execution  might  be  part 
of  the  supervisor,  and  the  procedure  invoked  by  cross-domain  call  2 
might  be  the  procedure  which  converts  a  symbolic  segment  name  provided 
as  an  input  argumenl  into  an  output  argument  that  is  a  pointer  to  the 
base  of  that  segment.  According  to  Figure  3-11,  this  zero  tag  will  be 
stored  in  the  indirect  address.  When  control  returns  to  domain  invoca¬ 
tion  2,  the  source  of  the  pointer  variable  output  argument,  the  zero 
tag  will  cause  references  through  this  pointer.  to  be  evaluated  relative 
to  the  static  access  capabilities  of  that  domain.  This  is  correct  since 
the  pointer  certainly  was  not  derived  from  an  argument  of  the  cross¬ 
domain  call  from  domain  invocation  1. 

In  case  2  the  pointer  in  PRji  was  derived  from  input  argument  B. 

The  source  of  this  argument  is  domain  invocation  2,  and  PRn  will  contain 
a  tag  of  two  propagated  from  PRja.  The  SPPn  instruction,  however,  will 
store  a  tag  value  of  zero  in  this  case,  sinca  PRn. TAG  =  TPR. TAG.  This 
is  the  correct  tag  from  che  viewpoint  of  domain  invocation  2,  since  this 
pointer  locates  part  of  a  data  base  that  is  statically  accessible  from 
that  domain.  It  is  also  the  correct  tag  from  the  point  of  view  of  the 
domain  of  execution.  If  this  stored  pointer  is  later  read  (using  an 
EPPji  instruction)  by  procedures  executing  in  this  domain  before  the 
cross-domain  return  to  domain  invocation  2  occurs,  then  the  fact  that 
the  stored  pointer  is  a  cross-domain  argument  with  domain  invocation  2 
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as  its  source  will  cause  a  tag  of  two  to  propagate  back  into  the  re¬ 
trieved  copy  of  the  pointer.  Thus,  from  the  point  of  view  of  the  domain 
of  execution,  no  information  is  lost  by  cancelling  the  tag  of  two  when 
the  pointer  is  stored. 

In  case  3  the  pointer  in  PRn  was  derived  from  input  argument  A. 

The  source  of  this  argument  is  domain  invocation  1,  and  PRn  will  contain 
a  tag  of  one  propagated  from  the  corresponding  argument  pointer  in  the 
argument  list  of  cross-domain  call  2.  In  this  case  the  tag  of  one  is 
stored  unaltered  in  the  pointer  variable,  for  PRn. TAG  <  TPR.TAG.  This 
is  the  correct  tag  from  the  viewpoint  of  domain  invocation  2,  since  the 
pointer  was  derived  from  an  argument  whose  source  was  domain  invocation 
1.  Use  of  the  pointer  variable  by  procedures  executing  in  domain  invo¬ 
cation  2  to  make  a  reference  should  be  validated  with  respect  to  the 
dynamic  access  capabilities  currently  in  this  domain.  It  is  also  the 
correct  tag  from  the  viewpoint  of  the  domain  of  execution,  since  it 
properly  indicates  the  source  ’omain  invocation  of  the  argument  from 
which  the  pointer  was  derived. 

Now  consider  the  use  of  pointer  variables  as  input  arguments  on 
cross-domain  calls.  This  use  of  pointer  variables  does  not  lead  to 
further  additions  to  the  processor  design,  but  instead  creates  a  new 
application  for  the  existing  protection  mechanisms.  Again,  the  dis¬ 
cussion  will  be  presented  in  terms  of  a  single  pointer  variable  used  as 
an  input  argument,  but  all  ideas  presented  can  be  applied  to  the  case 
of  an  input  argument  that  is  a  data  structure  containing  pointer 
variables. 
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The  usual  reason  for  passing  a  pointer  variable  as  an  input  argu¬ 
ment  is  to  explicitly  inform  the  called  procedure  of  the  location  cf  some 
data  item.  The  called  procedure  will  reference  the  data  item  through 
the  pointer  variable.  If  the  call  is  cross-domain,  and  the  data  item 
is  not  a  formal  argument  of  the  call,  then  a  problem  can  result,  for  no 
dynamic  access  capability  will  be  created  allowing  procedures  executing 
in  the  called  domain  invocation  to  reference  the  data  item.  While  it 
can  be  argued  that  passing  a  pointer  to  the  data  item  as  the  argument 
rather  than  the  data  item  itself  is  bad  programming  practice,  it  is 
frequently  done  anyway.  This  technique  allows  complex  PL/I  structures 
to  be  passed  as  implicit  arguments,  avoiding  the  syntactically  messy 
specification  of  the  structure  as  a  formal  argument.  The  technique  can 
also  be  used  to  pass  as  implicit  arguments  data  items  which  are  too  com¬ 
plex  to  be  expressed  as  formal  arguments  with  the  syntax  of  the  language. 

For  whatever  reason,  pointer  variables  are  used  in  input  arguments 
to  pass  implicit  arguments.  It  would  be  nice  if  the  protection 
mechanisms  of  the  processor  could  deal  with  this  case.  Fortunately  they 
can.  So  far  the  argument  list  associated  with  a  cross-domain  call  has 
beeu  treated  solely  as  a  specification  of  the  formal  arguments  of  the 
call.  The  argument  list-  serves  a  dual  purpose  when  a  call  is  cross¬ 
domain:  it  informs  the  called  procedure  of  Lhe  addresses  of  the  argu¬ 
ment  and  it  tells  the  processor  how  to  create  dynamic  access  capabilities. 
The  called  procedure  knows  how  many  iorraal  arguments  to  expect.  If 
extra  argument  list  entries  were  appended  to  the  end  of  the  argument 
list,  after  those  for  the  formal  arguments,  it  would  not  confuse  the 
called  procedure.  It  would,  however,  cause  the  processor  to  create 
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extra  dynamic  access  capabilities  in  the  case  of  a  cross-domain  call. 
This  property  can  be  used  to  cause  the  creation  of  dynamic  access  capa¬ 
bilities  allowing  access  to  implicit  arguments. 

If  a  compiler  is  to  generate  code  which  creates  at  the  end  of  the 
argument  list  generated  for  a  call  extra  argument  entries  for  implicit 
arguments,  then  the  compiler  somehow  needs  to  be  told  what  extra  entries 
are  to  be  created.  A  variety  of  high-level  language  extensions  can  be 
imagined  to  serve  this  purpose.  The  specific  extension  described  here 
fits  well  into  PL/I.  The  extension  is  a  built-in  function  named 
"window".  The  function  has  three  arguments:  a  pointer,  an  integer,  and 
a  one  bit  flag.  The  appearance  of  the  window  function  at  some  position 
in  the  argument  list  portion  of  a  call  statement  causes  an  argument 
entry  to  be  generated  at  the  corresponding  position  in  the  argument  list 
The  pointer  provided  becomes  the  pointer  in  the  first  word  of  the  entry, 
the  integer  becomes  the  size  in  the  second  word,  and  the  one  bit  flag 
controls  the  generation  of  the  read  and  write  permission  flags:  if  off 
then  only  read  permission  is  indicated,  if  on  then  both  read  and  write 

ic 

permission  are  indicated.  Window  functions  will  typically  appear  last 
in  the  list  of  arguments  for  a  call  statement,  and  will  define  the  sub- 
sfigGicuts  containing  tu6  implicit  arguments, 
j  Window  functions  can  be  used  to  create  fairly  complex  patterns  of 

;  access  permitsion.  In  particular,  one  window  function  (or  a  formal 

% 

argument)  can  provide  read  access  to  a  large  subsegment  while  several 

•fg  • 

Write  only  access  to  a  window  could  be  specified  as  well  by  expanding 
this  argument  to  two  bits. 
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other  window  functions  provide  read/write  access  to  selected  pieces  of 
that  subsegment. 

Window  functions,  then,  allow  input  arguments  that  are  pointer 
variables  to  be  used  to  pass  implicit  arguments.  The  pointer  variable 
is  listed  as  a  formal  argument  of  the  call  and  the  implicit  argument  is 
defined  by  one  or  more  window  functions  at  the  end  of  the  argument  list. 
It  can  be  argued  that  window  functions  are  contrary  to  the  criterion  of 
programming  generality.  Tn  a  sense  this  contention  is  correct.  A  call 
that  works  without  window  functions  in  cases  where  the  domain  of  execu¬ 
tion  is  not  changed  may  require  window  functions  to  work  cross-domain. 
The  only  answer  is  always  to  use  window  functions  when  implicit  argu¬ 
ments  are  being  passed,  even  if  the  call  is  not  expected  to  change  the 
domain  oi  execution.  The  extra  specification  provided  by  the  window 
functions,  while  not  functionally  required  for  calls  that  do  not  change 
the  domain  of  execution,  does  help  to  make  the  intention  of  the  program 
clearer  to  programmers  and  others  who  must  understand  the  symbolic 
program. 


The  Escape  Hatch 

The  protection  mechanisms  of  the  processor  are  built  upon  the 
philosophy  that  all  references  made  by  a  procedure  executing  in  some 
domain  invocation  through  pointers  derived  from  incoming  cross-domain 
arguments  should  be  validated  relative  to  the  dynamic  access  capabilities 
of  that  domain  invocation.  The  mechanisms  for  propagating  tags  cause 
this  kind  of  validation  of  all  such  references  as  a  matter  of  course. 
There  may  arise  circumstances,  however,  when  a  procedure  wishes  to 
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violate  this  philosophy  intentionally.  For  example,  two  domains  may 
share  static  access  to  a  segment.  A  procedure  executing  in  one  may  call 
a  procedure  that  executes  in  the  other  to  provide  the  latter  with  a 
pointer  to  the  shared  segment.  The  called  procedure  may  store  the 
pointer  as  an  internal  static  variable  to  be  used  later.  The  segment  is 
not  an  implicit  argument  of  the  cross-domain  call  and  no  dynamic  access 
capability  for  the  segment  ever  exists.  The  intentions  of  the  called 
procedure  are  properly  served  if  the  stored  pointer  has  a  tag  of  zero. 
Yet,  the  standard  pointer  manipulation  code  will  produce  d  non-zero  tag 
in  this  pointer,  for  it  is  related  to  a  cross-domain  argument.  In  cases 
such  as  this,  there  needs  to  be  a  way  to  force  the  tag  in  a  pointer  to 
zero.  For  this  purpose  a  built-in  function  should  be  provided. 

Such  a  function  for  PL/ I  might  be  named  "neutralize"  and  take  a 
single  pointer  as  its  argument.  The  result  is  another  pointer  with  the 
same  two-part  address,  but  a  tag  of  zero.  When  applied  to  pointers  that 
either  are  cross-domain  arguments  or  aro  derived  from  cross-domain  argu¬ 
ments,  neutralize  would  produce  an  equivalent  pointer  with  the  difference 
that  references  through  it  will  be  validated  with  respect  to  the  static 
access  capabilities  of  the  domain  cf  execution.  Needless  to  say,  a 
procedure  must  be  very  careful  when  applying  the  neutralize  function  to 
a  pointer,  for  use  of  this  function  has  the  potential  to  violate  the 
integrity  of  the  domain  of  execution. 

Processor  Response  to  Exceptional  Conditions 

Each  reference  made  by  an  executing  machine  language  program  to  a 
virtual  memory  location  is  validated  by  matching  it  to  the  static  or 
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dynamic  access  capabilities  in  the  domain  of  execution.  The  method  of 
validation  and  the  specific  conditions  under  which  a  given  reference 
will  be  allowed  have  been  discussed  in  some  detail.  An  important  point 
not  considered  yet  is  the  action  of  the  processor  in  cases  where  valida¬ 
tion  indicates  a  reference  should  not  be  allowed.  This  occurrence  is 
called  an  access  violation. 

An  access  violation  is  one  of  several  types  of  exceptional  condi¬ 
tions  that  the  processor  can  detect.  Other  examples  are  the  attempted 
execution  of  a  privileged  instruction  from  some  domain  other  than  domain. 
0,  the  detection  of  an  error  while  performing  a  cross-domain  call  or 
return,  an  attempted  reference  beyond  the  end  of  a  segment,  and  the 
attempted  use  of  an  invalid  segment  number.  There  may  be  many  other 
processor  detected  exceptions  as  well.  All,  including  access  violations, 
cause  the  processor  to  change  the  domain  of  execution  to  domain  0  and 
transfer  control  to  a  fixed  location.  Presumably  the  software  system 
is  arranged  so  that  this  location  is  the  beginning  of  the  supervisor 
procedure  which  responds  to  exceptions.  The  processor  is  arranged  so 
that  the  processor  state  at  the  time  of  the  exception  is  preserved. 

The  supervisor  procedure  can  inspect  this  state  information  to  determine 
the  precise  cause  of  the  exception.  Corrective  action  can  be  initiated 
if  appropriate.  A  privileged  instruction  allows  the  processor  state 
to  be  restored,  so  that  if  the  cause  of  the  exception  is  corrected  then 
the  disrupted  program  can  be  restarted  at  the  point  where  the  exception 
occurred. 

The  transfer  to  domain  0  in  the  case  of  an  exception,  although  it 
may  be  a  cross-domain  transfer,  does  not  affect  the  state  of  the  dynamic 
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access  stack  or  its  definition  register.  The  segment  containing  this 
stack,  as  well  as  the  descriptor  segment,  are  statically  accessible 
from  domain  0.  In  addition,  privileged  instruction  exist  to  load  and 
store  the  DSBR,  DR,  and  DASDR  of  the  processor.  Thus,  the  supervisor 
procedures  invoked  by  the  exception  are  able  to  make  any  necessary 
alterations  to  the  protection  environments  provided  by  the  various 
domains  of  the  process. 


An  Associative  Memory  for  Dynamic  Access  Capabilities 

As  indicated  earlier,  the  operation  of  validating  a  reference 
against  the  dynamic  access  capabilities  currently  in  the  domain  of 
execution  can  be  made  faster  in  the  case  that  multiple  references  match 
the  same  capability  by  adding  to  the  processor  a  small,  fast  associative 
memory  which  stores  the  most  recently  used  dynamic  access  capabilities. 
In  this  section  the  design  and  use  of  such  an  associative  memory  is 
presented.  Those  readers  generally  familiar  with  such  associative 
memories  can  skip  this  section  without  loss  of  continuity. 

The  associative  memory  ha?  a  smaJ 1  number  of  registers  (eight  is 
probably  more  than  enough),  each  of  which  can  hold  ail  fields  of  a 
dynamic  access  capability  for  read  and/or  write  access  to  a  subsegment. 
In  addition,  each  register  contains  a  few  bits  of  identification  and 
control  information.  The  format  c£  the  registers  is  shown  in  Figure 


3-13. 

This  associative  memory  (DAC-AM)  has  four  cycles:  SEARCH,  WRITE, 
CLEAR- FRAME,  and  CLEAR-ALL.  Consider  the  SEARCH  cycle  first.  Whenever 
a  reference  is  to  be  validated  with  respect  to  the  dynamic  access 
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input  parameters  for  search:  tag,  segment  number,  starting 
word  number,  ending  word  number,  type  of  reference 
(read  or  write),  current  DAS  frame  number  (DASDR.XDCC) 


output  from  search:  match  indicator,  source  domain  number  if 
match  occurred 


Figure  3-13:  Format  of  the  associative  memory  for  dynamic  access 
capabilities . 
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capabilities  currently  in  the  domain  of  execution,  the  DAC-AM  SEARCH 


cycle  is  invoked  before  a  linear  search  of  the  most  recent  DAS  frame  is 


performed.  The  input  parameters  to  the  SEARCH  cycle  are  listed  in 


Figure  3-1'''.  The  first  five  define  the  reference  being  made.  Both  a 


starting  and  ending  word  number  are  provided  so  that  double-word  (and 


larger  multiword)  references  can  be  validated.  The  last  input  parameter 


is  the  ..umber  of  the  current  DAS  frame,  as  recorded  in  DASDR.XDCC.  The 


hardware  performs  an  associative  search  of  all  DAC-AM  registers,  looking 


for  one  containing  a  dynamic  access  capability  which  allows  the  reference 


and  which  is  from  the  indicated  DAS  frame.  If  a  match  occurs,  then  a 


positive  match  indicator  is  the  result  and  the  SOURCE  field  from  the 


matching  capability  is  produced.  In  this  case  the  linear  search  of 


the  DAS  frame  in  memory  can  be  bypassed,  and  validation  of  the  reference 


can  proceed  to  the  stage  where  the  static  access  from  the  indicated 


source  domain  is  checked.  If  no  match  is  found,  then  a  negative  match 


indicator  is  the  result,  and  the  DAS  frame  in  memory  must  be  searched 


in  the  way  previously  described  for  a  matching  dynamic  access  capability. 


The  LRUCOUNT  field  of  DAC-AM  registers  is  used  to  order  the  dynamic 


access  capabilities  contained  in  the  DAC-AM  by  recency  of  use.  Each 


time  a  SEARCH  cycle  match  occurs,  the  LRUCOUNT  of  the  matching  register 


is  set  to  the  maximum  possible  value,  and  all  other  LRUCOUNT  fields  that 


are  greater  than  the  original  LRUCOUNT  value  of  the  matching  register 


Actually,  more  than  one  DAC-AM  register  may  contain  a  matching  capa¬ 
bility.  Since  the  SOURCE  fields  in  all  capabilities  that  match  will 
be  tne  same,  however,  it  does  not  matter  which  is  chosen  as  the  single 
matching  DAC-AM  register. 
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are  decremented  by  one. 

If  a  SEARCH  cycle  results  in  no  match,  but  the  linear  search  of 
the  DAS  frame  in  memory  does  succeed,  then  the  dynamic  access  capability 
found  this  way  is  entered  into  the  DAC-AM  using  the  WRITE  cycle.  The 
various  fields  of  this  capability  overwrite  the  contents  of  the  DAC-AM 
register  whose  LRUCOUNT  value  is  zero.  This  is  the  register  that  has 
gone  longest  without  producing  a  match.  The  FRAME  field  is  set  from 
DASDR.XDCC  to  indicate  the  DAS  frame  from  which  the  capability  came. 

The  LRUCOUNT  field  is  set  to  the  maximum  possible  value  and  the  LRUCOUNT 
fields  in  all  other  registers  are  decremented  by  one.  Thus,  the  DAC-AM 
always  contains  the  most  recently  used  dynamic  access  capabilities  for 
a  process.  Repeated  use  of  a  small  group  of  dynamic  access  capabilities, 
as  is  likely,  will  result  in  most  searches  of  the  DAC-AM  succeeding. 

As  a  result,  the  more  time-consuming  linear  search  of  the  DAS  frame  in 
memory  will  not  occur  each  time  dynamic  access  validation  is  required. 

When  a  cross-domain  call  occurs,  the  DAC-AM  can  be  used  in  two 
ways.  First,  it  can  be  applied  to  locating  a  matching  dynamic  access 
capability  in  the  previous  DAS  frame  when  constructing  a  new  dynamic 
access  capability  from  an  argument  entry  whose  pointer  has  a  non-zero 
tag.  (This  is  a  case  where  the  ability  of  the  DAC-AM  to  find  capa¬ 
bilities  matching  multiword  subsegments  is  used.)  Second,  it  can  be 
preloaded  explicitly  (using  the  WRITE  cycle)  with  the  newly  constructed 
capability  allowing  read  references  to  thr  argument  list  itself,  since 
the  likelyhood  of  this  capability  being  used  in  the  near  future  is 
great. 
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When  a  cross-domain  return  occurs  the  CLEAR- FRAME  cycle  of  the 
DAC-AM  is  invoked.  This  invalidates  all  registers  whose  FRAME  field 
indicates  that  the  contained  capability  is  from  the  DAS  frame  being  de¬ 
stroyed  by  the  return.  Invalidation  is  performed  by  setting  the  validity 
bit  (V)  off.  Only  registers  whose  validity  bit  is  on  can  match  on  a 
SEARCH  cycle.  The  LRUCOUNT  fields  in  all  registers  so  invalidated  are 
adjusted  so  that  these  registers  will  be  the  next  to  be  overwritten. 

The  final  cycle,  CLEAR-ALL,  is  used  when  the  process  is  execution 
on  the  processor  is  changed.  It  causes  all  registers  to  be  invalidated. 

The  DAC-AM  will  decrease  the  time  required  to  validate  a  reference 
against  dynamic  access  capabilities  only  in  the  case  that  multiple 
references  are  validated  against  the  same  capability.  It  will  almost 
always  be  the  case  that  the  capability  giving  read  access  to  a  cross¬ 
domain  argument  list  will  be  used  several  times.  Multiple  references 
to  individual  arguments  are  not  uncommon  —  particularly  to  arguments 
that  are  large  arrays  or  structures.  Considering  the  low  cost  of  such 
an  associative  memory  and  the  off-the-shelf  ava.' lability  of  the  control 
logic  for  performing  the  associative  search  and  updating  the  LRU  counters, 
the  DAC-AM  seems  like  a  good  investment. 

In  addition  to  the  DAC-AM,  the  processor  also  can  contain  a  similar 
associative  memory  for  the  most  recently  used  descriptor  segment  entries 
(DSE's).  Associative  memories  for  address  translation  table  entries  are 


There  is  no  reason  to  put  return  gate  capabilities  in  the  DAC-AM,  since 
each  is  used  only  once.  The  position  of  die  return  gate  capability  in 
a  DAS  frame  is  always  known  so  no  search  of  the  DAS  frame  is  required 
to  find  it  in  any  case. 
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of  proven  value  in  reducing  the  average  time  required  to  translate  an 
address  [24]. 

Entry  and  Label  Variables 

In  PL/I,  entry  and  label  variables  may  be  passed  as  arguments  on 
interprocedure  calls.  It  is  possible  for  the  called  procedure  to  per¬ 
form  a  goto  operation  on  a  label  variable  received  as  an  argument  and 
to  perform  a  call  operation  on  an  entry  variable  received  as  an  argument. 
The  processor  as  currently  defined  can  handle  neither  of  these  cases 
automatically  if  the  call  which  passes  the  entry  or  label  variable  as 
an  argument  is  cross-domain.  The  techniques  underlying  the  processor 
protection  mechanisms  described  so  far,  however,  can  he  applied  to 
these  cases  as  well.  This  section  investigates  the  processor  extensions 
that  would  be  required  for  allowing  entry  and  label  variables  to  be 
used  as  arguments  of  cross-domain  calls. 

Presentation  of  the  material  of  this  section  is  not  meant  to  imply 
that  the  facility  to  pass  entry  and  label  variables  cn  cross-domain 
calls  must  be  included  in  the  processor  if  it  is  to  be  practical.  In¬ 
deed,  a  good  case  can  be  made  for  omitting  this  facility  considering 
the  additional  complexity  that  it  introduces.  The  section  is  included 
in  the  thesis  only  to  illustrate  a  more  sophisticated  application  of 
the  basic  techniques  used  in  the  processor  than  has  been  presented  so 
far  in  this  chapter. 

First  consider  entry  variables.  As  usually  implemented  an  entry 
variable  is  a  pair  of  pointers.  The  first  locates  an  entry  point  while 
the  second  locates  an  activation  record.  If  Che  entry  variable  locates 
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an  entry  point  into  the  outermost  level  of  a  nested  set  of  PL/I  proce¬ 
dures,  i.e.,  an  external  entry  point,  then  the  second  pointer  means 
nothing.  If  the  entry  variable  locates  an  entry  point  into  one  of  the 
inner  layers,  i.e.,  an  internal  entry  point,  then  tne  second  pointer 
locates  an  already  existing  activation  record  that  corresponds  to  some 
unreturned  invocation  of  the  containing  procedure.  When  a  call  through 
an  entry  variable  to  an  internal  entry  point  occurs,  this  activation 
record  pointer  must  be  made  available  to  the  called  procedure  to  define 
part  of  its  addressing  environment. 

A  standard  implementation  of  a  call  through  an  entry  variable 
needs  to  be  defined,  just  as  a  standard  inLerprocedure  call  was  defined 
earlier.  The  implementation  chosen  is  substantially  the  same  as  that 
for  a  normal  interprocedure  call.  The  only  difference  i?  that  the  two 
instructions: 

EPP_s  "entry  variable" Tl,* 

CALL  "entry  variable"*!),* 

where  "entry  variable"  represents  the  address  of  the  entry  variable, 
are  used  in  place  of  the  single  CALL  instruction  of  the  standard  inter¬ 
procedure  call.  The  first  instruction  loads  PRjs  with  the  second  pointer 
from  the  entry  variable.  The  second  instruction  is  the  previously  de¬ 
fined  CALL  instruction  with  an  operand  address  specification  that 
locates  the  entry  point  specified  by  the  first  pointer  in  the  entry 
variable.  As  a  result  or  a  call  through  an  entry  variable,  the  called 
procedure  can  expect  to  find  PRa  containing  a  pointer  to  the  argument 
list,  PRb  containing  a  pointer  to  the  base  of  the  stack  segment  in  which 
a  new  activation  record  should  be  created,  and  PRs  containing  the  second 


pointer  from  the  entry  variable.  If  the  called  entry  point  is  external, 
then  the  called  procedure  will  ignore  pointer  in  PRa.  If  it  is  internal, 
then  the  pointer  in  PRa  will  be  used  by  the  called  procedure  to  locate 
variables  belonging  to  the  appropriate  outstanding  invocation  of  the 
enclosing  procedure  block.  That  a  call  is  through  an  entry  variable  is 
apparent  to  the  compiler,  so  it  can  choose  properly  whether  to  generate 
the  code  for  a  standard  interprocedure  call  or  the  code  for  a  call 
through  an  entry  variable. 

There  are  a  variety  of  ways  to  use  entry  variables  as  arguments. 

They  may  appear  singly,  in  arrays,  or  as  elements  of  non-homogeneous 
data  structures.  Consideration  of  the  simple  case  of  a  single  entry 
variable  passed  as  an  individual  argument,  however,  demonstrates  the 
problems  generated  by  the  use  of  entry  variable  arguments  on  cross-domain 
calls.  Imagine  that  procedure  A  passes  an  entry  xriable  as  an  input 
argument  on  a  call  to  procedure  B  with  the  intention  that  B  (or  a 
descendant  procedure)  perform  a  call  through  this  entry  variable.  With 
the  protection  mechanisms  defined  so  far.  an  argument  list  like  that 
illustrated  in  Figure  3-14  would  be  generated  by  A.  An  argument  list 
entry  specifies  read  access  to  the  two  word  entry  variable.  If  the 
A  to  B  call  is  cross-domain,  a  dynamic  access  capability  will  be  gener¬ 
ated  which  allows  procedures  executing  in  the  called  domain  read  access 
to  the  entry  variable. 

When  time  comes  for  B  to  make  the  call  through  the  entry  variable 
a  temporary  pointer  to  the  entry  variable  will  be  generated  in  PRn 
with  the  instruction: 

EPPn  PRa tm, * 
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where  m  is  the  offset  of  the  argument  list  entry  for  the  entry  variable. 
Ther  an  argument  list  will  be  created  and  PRa  set  with  a  pointer  to  it. 
Finally,  the  call  through  the  entry  variable  will  be  made  by  procedure 
B  with  the  instructions: 

EPPs 

CALL  PRntO,* 

Because  the  entry  variable  itself  is  a  cross-domain  argument,  the  tempo¬ 
rary  pointer  to  it  generated  in  PRn  will  have  a  non-zero  tag.  This  tag 
causes  the  indirect  word  read  reference  to  the  entry  variable  generated 
by  the  EPPs^  instruction  to  be  validated  relative  to  the  dynamic  access 
capabilities  in  B’s  domain  invocation.  This  reference  will  succeed 
by  matching  the  capability  allowing  read  access  to  the  entry  variable; 
likewise  for  the  indirect  word  read  reference  caused  by  the  CALL 
instruction.  The  final  effective  pointer  generated  by  the  CALL  instruc¬ 
tion  also  will  have  a  non-zero  tag  —  indicating  that  the  call  is  to  be 
validated  with  respect  to  dynamic  access  capabilities  in  B's  domain  of 
execution.  It  is  here  where  the  protection  mechanisms  defined  in  the 
previous  section  are  inadequate.  So  matching  dynamic  access  capability 
can  be  found  because  dynamic  access  capabilities  allowing  call  access 
to  an  entry  point  have  not  been  defined.  The  protection  mechanisms  dis¬ 
cussed  so  far  only  can  handle  the  case  of  a  CALL  instruction  which 
generates  a  tag  of  zero  in  its  effective  pointer.  The  extension  required 
to  allow  the  use  of  entry  variables  as  cross-domain  arguments  is  the 
introduction  of  a  new  dynamic  access  capability  type  for  call  access 
to  an  entry  point.  Th  call  access  capability  must  contain  both 
pointers  from  the  entry  variable  so  that  both  the  location  to  which  the 
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call  is  directed  and  the  activation  record  pointer  loaded  into  PRs  can 
be  verified. 

One  way  to  implement  call  access  capabilities  is  to  add  an  entry 
variable  identification  flag  to  the  read  and  write  permission  flags 
that  may  already  appear  in  argument  list  entries.  If  this  entry 
variable  identification  flag  is  set  on,  then  the  subsegment  located  by 
the  argument  list  entry  is  specified  to  be  an  entry  variable  (or  an 
array  of  entry  variables  if  the  indicated  size  is  greater  than  two  words) 
for  which  a  dynamic  access  capability  allowing  call  access  should  be 
constructed  when  a  cross-domain  call  occurs.  If  an  input  argument  is 
an  entry  variable  (or  an  array  of  enLry  variables),  then  the  correspond¬ 
ing  argument  list  entry  has  both  the  read  permission  flag  and  the  entry 

* 

variable  identification  flag  set  on  .  If  th*1  call  is  cross-domain,  then 
because  of  the  read  permission  flag  the  processor  will  generate  a  dynamic 
access  capability  allowing  read  access  to  the  subsegment  containing  the 
€  :try  variable  as  before,  and  because  of  the  entry  variable  identifica¬ 
tion  flag  the  processor  will  generate  a  capability  allowing  call  access 
to  the  entry  point  located  by  the  entry  variable.  (In  the  case  of  an 
array  of  entry  variables  a  call  access  capability  mast  be  generated  for 
each  element  in  the  airay.)  The  call  access  capability  contains  the 


It  seems  a  safe  assumption  that,  when  an  entry  variable  is  passed  as  an 
input  argument,  the  calling  procedure  intends  for  the  called  procedure 
to  call  through  the  entry  variable.  Thus,  the  compiler  can  always 
generate  code  to  set  the  entry  variable  identification  flag  on  for  input 
arguments  that  are  entry  variables.  For  entry  variables  that  are  output 
arguments  the  read  and  write  permission  flags  should  be  set  on,  but  the 
entry  variable  identification  flag  should  be  left  off. 
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segment  and  word  number  portions  from  both  the  entry  point  pointer  and 

the  activation  record  pointer  in  the  entry  variable.  It  also  contains 

a  TAG  and  a  SOURCE  field  like  read/write  dynamic  access  capabilities. 

The  TAG  field  identifies  the  domain  invocation  that  is  the  original 

source  of  the  capability  while  the  SOURCE  field  contains  the  number  of 
* 

that  domain. 

With  the  addition  of  call  access  capabilities,  then,  CALL  instruc¬ 
tions  which  generate  an  effective  pointer  with  a  non-zero  tag  can  be 
handled.  When  this  case  is  encountered,  the  most  recent  DAS  frame  is 
searched  for  a  call  access  capability  allowing  the  intended  call.  In 
order  for  the  call  to  be  allowed,  a  call  access  capability  must  be  found 
whose  TAG  field  matches  the  tag  from  the  effective  pointer,  whose  entry 
point  pointer  segment  and  word  numler  match  the  segment  and  word  number 
in  the  effective  pointer,  and  whose  activation  record  pointer  segment 
and  word  number  match  the  segment  and  word  number  in  PRs.  The  call 
must  also  be  allowed  by  the  static  access  capabilities  of  the  SOURCE 
domain  indicated  by  the  matching  call  access  capability.  If  the  call 


When  determining  the  source  domain  invocation  for  a  call  access  capa¬ 
bility  both  the  tag  of  the  pointer  in  the  argument  list  entry  and  the 
tag  of  the  entry  point  pointer  in  the  entry  variable  must  be  taken  into 
consideration.  If  the  source  is  the  domain  invocation  from  which  the 
cross-domain  call  is  coming,  then  both  tags  will  be  zero.  In  this  case 
the  TAG  field  of  the  capability  is  set  to  the  number  of  the  domain 
invocation  from  which  the  call  is  coming  and  the  SOURCE  field  is  set  to 
match.  If  the  source  is  an  earlier  domain  invocation,  however,  then 
the  tag  from  either  pointer  may  indicate  this  fact.  Ir  this  case  the 
smallest  non-zero  tag  of  the  two  indicates  the  source  domain  invocation 
number  to  be  recorded  in  the  TAG  field  of  the  capability.  The  previous 
DAS  frame  must  be  searched  for  a  matching  call  access  capability  and 
the  SOURCE  field  value  from  the  matching  capability  copied  into  the 
new  capability. 
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is  allowed,  then  the  CALL  instruction  completes  in  the  manner  discussed 
earlier.  The  value  of  Pite.TAG  is  forced  to  zero  as  the  transfer  occurs. 
(The  called  procedure,  if  the  call  is  to  an  internal  entry  point,  always 
wants  static  access  to  the  activation  record  of  the  containing  proce¬ 
dure  block,  and  the  tag  in  PRs^  may  be  set  erroneously  to  a  non-zero 
value  for  the  same  reason  that  the  tag  in  the  pointer  restored  to  PRs 
before  a  cross-domain  return  erroneously  is  non-zero.) 

Notice  that  a  call  through  a  cross-domain  argument  that  is  an  entry 
variable  may  not  be  a  cross-domain  call,  even  though  it  is  validated 
by  matching  a  dynamic  access  capability.  If  the  call  is  to  an  internal 
entry  point  then  it  may  be  an  internal  entry  point  of  a  procedure  invo¬ 
cation  executing  in  an  earlier  outstanding  invocation  of  the  calling 
domain.  If  the  call  is  to  an  external  entry  point  then  it  may  be  a 
gate  entry  point  back  into  the  calling  domain,  which  gate  is  statically 
accessible  from  the  source  domain  of  the  dynamic  access  capability  that 

JU 

allows  the  call. 


The  processor  described  in  this  chapter  does  not  allow  procedures 
executing  in  some  domain  to  use  the  dynamic  access  capabilities  of  an 
earlier  outstanding  invocation  of  the  same  domain.  This  restriction 
is  required  to  prevent  a  cross-domain  return  from  jumping  several 
outstanding  domain  invocations  without  giving  procedures  that  execute 
in  these  domain  invocations  a  chance  to  place  the  encapsulated  sub¬ 
systems  in  a  consistent  state.  A  cross-domain  call  through  an  entry 
variable,  however,  can  generate  a  legitimate  need  for  a  procedure 
executing  in  some  domain  to  use  the  dynamic  access  apabilities  (other 
than  the  return  gate  capability)  of  an  earlier  outstanding  invocation 
of  the  same  domain.  It  is  straightforward  to  extend  the  processor  to 
handle  this  case  properly.  The  extension  requires  expanding  the  tags 
in  pointers  and  dynamic  access  capabilities  to  contain  one  bit  for  each 
domain  invocation  which  can  exist  at  one  time.  The  expanded  tags  allow 
the  specification  to  be  made  that  a  reference  be  validated  with  respect 
to  the  dynamic  access  capabilities  of  an  earlier  invocation  of  the 
domain  that  is  the  domain  of  execution. 
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Label  variables  are  very  similar  to  entry  variables,  and  also  are 
normally  implemented  as  a  pair  of  pointers.  The  first  pointer  locates 
the  start  of  the  machine  code  corresponding  to  some  labeled  statement  of 
a  program  and  the  second  is  an  activation  record  pointer  which  identi¬ 
fies  the  procedure  invocation  which  goes  with  that  label.  The  goto 
operation  on  a  label  variable  involves  destroying  all  stacked  activation 
records  between  the  activation  record  for  Lhe  procedure  which  performs 
the  goto  and  the  activation  record  indicated  in  the  label  variable. 

Along  the  way,  the  appropriate  condition  handlers  defined  in  the  acti¬ 
vation  records  being  destroyed  will  be  invoked.  When  the  stack  is 
properly  unwound,  then  a  transfer  to  the  indicated  procedure  segment 
location  occurs.  Because  of  its  complexity,  this  non-local  goto  opera- 
ti ra  through  a  label  variable  is  normally  implemented  by  compiler 
generated  code  which  calls  upon  a  system-provided  stack  unwinding  pro¬ 
gram.  In  the  case  of  the  processor  design  described  here,  the  same 
approach  can  be  used.  This  unwinding  program  is  easiest  to  construct 
if  it  executes  in  domain  0  where  it  will  have  access  to  all  activation 
record  stack  segments  and  the  DAS.  The  processor,  however,  can  be  ex¬ 
panded  a  little  to  make  the  job  of  the  unwinding  -ogram  a  little  easier. 

If  a  label  variable  is  passed  as  an  input  argument  on  a  cross-domain 
call  then  a  goto  operation  on  that  label  by  a  procedure  executing  in  the 
called  domain  will  unwind  the  activation  record  stack  and  the  DAS  back 
through  unreturned  cross-domain  calls.  The  transfer  of  control  to  the 
label  may  change  the  domain  of  execution.  By  adding  a  label  variable 
identification  flag  to  argument  list  entries,  and  extending  the  processor 
to  create  goto  access  capabilities  for  label  variables  on  cross-domain 
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calls,  the  processor  can  help  the  unwinding  procedure  to  determine  that 
an  attempted  cross-domain  goto  is  allowed.  The  unwinding  procedure 
merely  need  look  in  the  most  recent  DAS  frame  for  a  matching  goto  access 
capability  to  determine  if  the  attempted  cross-domain  goto  should  be 
performed.  The  goto  access  capability  is  analogous  to  the  call  access 
capability  in  the  way  it  is  constructed  and  the  information  it  must 
contain. 
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Bit  Addressing 

For  simplicity  of  explanation,  the  processor  presented  in  this 
chapter  is  word  addressed.  This  allows  the  problem  of  associating  an 
explicit  length  with  each  reference  to  be  ignored,  for  all  references 
have  an  implied  length  of  one  or  two  words.  When  passing  arguments 
with  cross-domain  calls  and  referencing  arguments  of  cross-domain  calls, 
however,  the  ultimate  precision  of  specifying  references  by  bit  address 
and  bit  length  can  be  very  useful. 

To  see  the  usefulness  of  full  bit  addressing,  consider  passing 
a  bit  string  of  length  7  as  an  input  argument  on  a  cross-domain  call. 
With  the  word  addressed  machine  the  corresponding  argument  list  entry 
and  dynamic  access  capability  *  ill  specify  the  one  or  two  word  sub- 
segment  necessary  to  cover  the  bit  string.  Additional  information  may 
have  to  be  communicated  to  the  called  procedure,  either  in  the  argument 
list  or  another  argument,  to  specify  the  location  of  the  bit  string 
within  the  larger  subsegment.  Procedures  executing  in  the  called  domain 
will  have  read  access  to  the  entire  subsegment,  although  only  a  bit 
string  of  length  7  is  the  argument.  If  the  string  is  embedded  in 
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other  information  which  the  calling  procedure  wants  to  be  certain  does 
not  become  accessible  to  the  called  procedure*  then  the  bit  string  must 
be  copied  into  a  wor’  that  contains  no  other  valuable  information  before 
the  call  is  made,  and  the  copy  passed  as  the  argument.  With  a  bit 
addressed  machine  the  exact  seven  bits  holding  the  string  could  be 
specified  as  an  argument,  and  a  dynamic  access  capability  created  giving 
read  access  to  that  subsegment  of  seven  bits.  No  copy  would  have  to  be 
made  to  avoid  giving  the  called  procedure  access  to  adjacent  bits. 

The  protection  techniques  presented  in  this  chapter  apply  equally 
well  to  a  bit  addressed  machine.  The  essential  changes  required  are 
extending  the  length  of  the  displacement  portion  of  a  pointer  to  hold  a 
bit  number  rather  than  a  word  number,  and  devising  means  to  associate 
the  proper  length  with  all  references.  Working  through  the  hardware 
mechanisms  required  to  generate  the  proper  length  information  for  each 
reference  appears  to  be  the  most  difficult  problem  encountered  when 
applying  the  techniques  presented  in  this  chapter  to  a  bit  addressed 
machine. 


Summary 

This  chapter  described  a  hardware  processor  that  supports  a  multi- 
domain  computation  implemented  as  a  single  execution  point  in  a  seg¬ 
mented  virtual  memory  and  that  automatically  performs  cross-domain  calls. 
The  processor  recognizes  static  access  capabilities  allowing  read, 
write,  and/or  execute  access  to  segments  and  allowing  procedures  execute 
ing  in  one  domain  to  carl  gate  entry  points  into  another  domain.  Dynamic 
access  capabilities  allowing  read  and/or  write  access  to  subsegments 
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representing  arguments  are  automatically  created  in  a  processor  managed 
dynamic  access  stack  when  a  cross-domain  call  occurs,  along  with  a 
dynamic  access  capability  allowing  access  to  the  return  gate  for  the 
call.  The  standard  argument  list  of  an  interprocedure  call  is  used  by 
the  processor  as  the  specification  of  what  capabilities  to  create. 

These  capabilities  are  automatically  destroyed  when  the  corresponding 
cross-domain  return  occurs. 

The  processor  is  organized  so  that  all  addresses  related  to  cross¬ 
domain  arguments  are  automatically  tagged  with  the  number  of  the  source 
domain  invocation  for  the  argument.  This  tag  causes  validation  of 
references  through  such  addresses  to  be  with  respect  to  the  dynamic 
access  capabilities  currently  part  of  the  domain  of  execution.  As  long 
as  addresses  are  manipulated  using  the  EPPjn  and  SPPn  instructions,  the 
relationship  of  an  address  to  a  cross-domain  argument  is  never  lost. 
Recursive  invocation  of  domains  and  the  passing  of  arguments  through 
multiple  consecutive  cross-domain  calls  do  not  confuse  the  address 
tagging  mechanism.  The  failure  of  a  machine  code  procedure  to  utilize 
properly  this  and  other  processor  protection  mechanisms,  however,  can 
only  compromise  the  integrity  of  the  domains  in  which  that  procedure 
executes. 

While  the  protection  mechanisms  described  in  the  chapter  may  seem 
complex  when  viewed  at  the  level  of  the  hardware,  this  complexity  is  not 
apparent  to  the  users.  The  users  control  the  cross-domain  call  mechanisms 
directly  from  h'.gh-level  programming  languages.  The  call  statement  of  a 
language  like  PL/1,  with  the  simple  extension  that  arguments  be  declared 
as  input  or  output  arguments,  and  the  special  built-in  functions  "window” 
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and  "neutralize"  are  all  that  the  programmer  needs  to  direct  the  cross¬ 
domain  call  mechanisms  and  properly  control  access  to  arguments. 

Tha  processor  developed  in  this  chapter  provides  a  hardware  basis 
for  a  computer  utility  in  which  users  may  encapsulate  independently 
compiled  programs  and  associated  data  bases  as  protected  subsystems, 
and  then,  without  compromising  the  protection  of  the  individual  sub¬ 
systems,  combine  protected  subsystems  of  different  users  to  perform 
various  computations.  The  software  system  required  to  produce  such  a 
facility  based  on  this  processor  is  discussed  in  the  next  chapter. 


CHAPTER  4 


SOME  COMMENTS  ON  THE  SUPPORTING  SOFTWARE 
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In  this  chapter  a  software  second  layer  for  the  processor  protec¬ 
tion  mechanisms  developed  in  Chapters  2  and  3  is  briefly  discussed.  The 
purpose  of  the  material  in  this  chapter  is  not  to  provide  a  detailed 
development  of  the  complex  issues  involved  in  providing  a  proper  user 
interface  for  controlling  sharing  in  a  computer  utility.  Rather,  it 
is  simply  to  demonstrate  one  way  of  harnessing  the  processor  protection 
mechanisms  so  that  users  can  define  and  control  the  sharing  of  protected 
subsystems. 

As  stated  in  Chapter  1,  the  goal  of  the  research  reported  in  this 
thesis  is  to  develop  a  computer  utility  in  which  mutually  suspicious 
subsystems  can  cooperate  in  a  single  computation  in  an  efficient  and 
natural  way.  A  specific  objective  derived  from  this  goal  is  that  a 
{programming  environment  be  provided  in  which  procedure  segments,  data 
segments,  and  protected  subsystems  of  all  users  can  be  treated  as 
building  blocks  and  combined  in  a  controlled  way  into  different  compu¬ 
tations.  The  starting  point  of  the  research  was  Multics,  which  to  a 
large  extent  already  provides  the  building  block  facility  with  respect 
to  procedure  and  data  segments,  but  which  allows  protected  subsystems 
to  be  defined  and  manipulated  only  in  restricted  ways.  The  primary 
obstacle  to  providing  a  general  facility  for  manipulating  protected  sub¬ 
systems  in  Multics  is  the  restriction  that  the  domains  of  a  process  be 
totally  ordered  with  respect  to  contained  access  capabilities.  The 
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processor  discussed  in  Chapters  2  and  3  removes  this  restriction. 

With  the  primary  obstacle  out  of  the  way,  only  a  few  asp  :cts 
of  the  Multics  software  system  need  to  be  extended  to  produce  a  first 
app.  cimation  to  a  software  system  which  can  affectively  apply  the  hard¬ 
ware  protection  mechanisms  to  generate  an  environment  in  which  protected 
subsystems  may  be  manipulated  in  a  natural  way  by  all  users.  The  most 
significant  changes  required  are  the  expansion  of  the  file  system  to 
catalogue  protected  subsystems  as  well  as  segments  and  the  recasting  of 
control  lists  in  terms  of  protected  subsystem  names  rather  than  domain 
numbers.  These  extensions  are  outlined  in  this  chapter. 

Because  this  chapter  is  intended  only  to  provide  an  example  of  how 
the  processor  protection  mechanisms  can  be  harnessed  by  a  software 
system,  little  justification  or  detail  is  provided  for  those  aspects  of 
the  software  that  are  derived  directly  from  Multics.  The  reader  is 
referred  to  the  book  by  Organick  [34]  for  a  detailed  discussion  of  the 
Multics  facilities  outlined  here. 

A  Distributed  Superv isor 

The  distributed  supervisor  organization  used  in  Multics  is  easily 

implemented  on  the  new  processor.  When  a  user  logs  in  to  the  system  a 

process  with  a  new  virtual  memory  is  created  for  him.  Initially  two 

domains  of  the  process  are  occupied.  Domain  0  encapsulates  the  super- 
* 

visor.  Thus,  the  supervisor  is  a  protected  subsystem  that  is  part  of 


Domain  0  is  chosen  because  of  the  special  treatment  afforded  it  by  the 
processor.  In  Multics,  the  supervisor  is  encapsulated  in  the  largest  of 
the  linearly  nested  domains  of  a  process. 
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every  process.  Another  domain  encapsulates  a  "home"  protected  sub¬ 
system  for  the  user.  When  the  user  first  gains  control  of  the  process 
it  is  executing  in  this  home  domain  in  some  procedure  which  interprets 
as  commands  characters  input  from  his  terminal. 

Because  the  supervisor  is  a  protected  subsystem  that  is  part  of  the 
process,  the  supervisor  can  be  invoked  by  standard  interprocedure  calls 
to  the  gate  entry  points  into  domain  0  to  perform  various  services  for 
the  process.  (It  may  also  be  invoked  by  generating  an  exception,  for 
an  exception  forces  control  into  domain  0.)  Among  the  services  of 
interest  here  are  adding  various  segments  stored  on-line  to  the  virtual 
memory  of  the  process  and  associating  various  protected  subsystems 
whose  definitions  are  stored  on-line  with  unoccupied  domains  of  the 
process. 

The  File  System 

In  Mu 1 tics  all  segments  stored  on-line  are  catalogued  by  a  file 
system  which  is  implemented  as  a  set  of  procedure  and  data  segments  in 
the  supervisor.  The  single,  system  wide  catalogue  is  arranged  as  a 
tree-structured  directory  hierarchy.  Each  directory  contains  entries 
giving  the  attributes  of  all  directly  inferior  directories  and  segments. 
The  attributes  in  each  entry  include  a  name,  a  length,  a  beginning 
absolute  address,  and  an  access  control  list.  The  name  in  a  directory 
entry  uniquely  identifies  the  entry  in  that  directory.  Each  directory 
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Directories  are  implemented  as  data  segments  which  can  be  read  and 
written  only  from  the  supervisor  domain. 
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or  segment  can  be  uniquely  located  in  the  tree-structured  directory 
hierarchy  by  a  multicomponent  tree  name  consisting  of  an  ordered  list 
of  directory  entry  names  defining  a  path  from  the  base  of  the  tree  — 
the  "root"  directory  --to  the  item  of  interest.  Figure  4-1  illustrates 
a  directory  hierarchy  and  gives  the  tree  names  of  the  items  shown.  The 
symbol  ">"  is  used  as  a  separator  for  the  components  of  a  tree  name. 

The  directory  hierarchy  allows  a  content-related  organization  to  be 
imposed  on  all  information  stored  on-line  in  the  system.  The  structure 
of  the  initial  layers  of  the  hierarchy  usually  will  be  quite  static  and 
will  be  known  by  most  system  users.  Figure  4-2  illustrates  a  structure 
similar  to  that  used  in  Multics  to  organize  on-line  storage.  This 
structure  reflects  the  fact  that  the  people  who  use  the  system  are 
grouped  for  administrative  purposes  into  various  projects.  (A  user  name 
in  this  case  is  the  concatenation  of  a  project  name  and  a  person  name.) 
Each  user  has  a  home  directory  in  which  to  create  an  arbitrary  substruc¬ 
ture  of  segments  and  directories.  Each  existing  process  has  a  directory 
in  which  to  place  all  its  temporary  data  segments  such  as  its  descriptor 
segment^  stack  segments,  etc.  Other  areas  of  the  hierarchy  catalogue 
library  and  system  segments. 

There  are  a  variety  of  operations  which  may  be  performed  on  the 


directory  hierarchy  by  calling  the  appropriate  supervisor  gate  entry 
point.  Examples  are  creating  or  deleting  an  object  in  some  directory. 


changing  the  attributes  of  an  existing  object,  listing  the  entry  names 


in  a  directory,  and  adding  a  segment  to  the  virtual  memory  of  the 
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process.  Whether  or  not  a  particular  requested  operation  on  some 
object  will  be  performed  is  controlled  by  the  access  control  list  (ACL) 
of  the  object.  The  supervisor  compares  the  name  of  the  user  associated 
with  the  process  being  executed  and  the  number  of  the  domain  from  which 
the  request  is  made  with  the  ACL  of  the  object.  If  some  ACL  element 
containing  a  matching  name  and  number  is  found,  then  the  various  per¬ 
mission  flags  set  in  that  element  determine  whether  or  not  the  requested 
operation  will  be  performed.  If  no  matching  element  is  found  then  the 
requested  operation  will  not  be  performed.  Each  ACL  entry  essentially 
defines  some  capabilities  included  in  the  specified  domain  of  a  process 
of  the  specified  user.  The  permission  flags  present  determine  the 
particular  kinds  of  access  allowed  by  the  capabilities.  The  flags  that 
may  appear  in  an  element  of  a  directory  ACL  provide  independent  control 
on  operations  like  listing  the  entries  in  that  directory,  creating  new 
objects  in  that  directory,  and  changing  certain  attributes  recorded  in 
enLries  in  that  directory.  The  last  case  includes  changing  the  ACL's 
in  these  entries.  The  permission  flags  that  may  appear  in  an  element 
of  a  segment  ACL  can  indicate  read,  write,  execute,  and  gate  access 
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to  that  segment. 

The  flaw  in  this  access  specification  scheme  used  by  Multics,  when 
applied  to  controlling  the  sharing  of  protected  subsystems  with  the  new 
processor,  is  that  actual  domair  numuers  appear  in  ACL  elements.  The 
implication  of  this  fact  is  that  a  particular  domain  of  a  process  of  a 


In  Multics  this  last  operation  is  normally  caused  by  a  dynamic  linking 
exception  rather  than  an  explicit  call  to  the  supervisor. 
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particular  user  always  protects  the  same  protected  subsystem.  An  exten¬ 
sion  that  eliminates  this  flaw  is  to  make  protected  subsystems  named 
objects  that  are  catalogued  in  the  directory  hierarchy  and  to  replace 
the  domain  number  in  an  ACL  element  with  the  tree  name  of  a  protected 
subsystem.  Then  any  protected  subsystem  may  be  associated  with  any 
domain  of  a  process  as  the  need  arises.  The  numbered  domains  of  a 
process  are  allocated  to  protected  subsystems  just  as  segment  numbers 
in  the  virtual  memory  of  the  process  are  allocated  to  segments  stored 
on-line.  With  this  revised  scheme  the  access  of  procedures  executing 
in  some  domain  of  a  process  is  determined  by  the  name  the  protec ced 
subsystem  associated  with  the  domain  and  the  name  of  the  user  associated 
with  the  process,  rather  than  the  domain  number  and  the  user  name.  This 
approach  is  now  explored  in  a  little  more  detail. 


Protected  Subsystems 

A  protected  subsystem  is  a  third  type  of  object  which  may  be  defined 
by  a  directory  entry.  The  attributes  of  a  protected  subsystem  are  a 
name  and  an  ACL.  A  protected  subsystem  has  no  content,  so  attributes 
such  as  length  and  address  are  not  required.  The  ability  to  create  a 
new  protected  subsystem  in  some  directory  or  delete  a  protected  sub¬ 
system  from  a  directory  is  controlled  by  the  ACL  of  the  directory,  as  it 
is  for  the  other  two  types  of  objects  which  may  be  defined  by  a  directory 
entry. 

The  ACL  for  a  directory,  segment,  or  protected  c_Lsystem  is  a  list 
of  two-component  elements  of  the  following  form: 

<protected  subsystem  tree  name>:<user  name>  <mode> 


The  first  component  identifies  an  instance  of  use  of  a  particular  pro¬ 
tected  subsystem  in  a  process  of  a  particular  user.  The  second  com¬ 
ponent  is  some  set  of  permission  flags  appropriate  for  the  object  type. 

By  means  to  be  discussed  in  a  moment  it  is  possible  to  associate 
a  protected  subsystem  with  one  of  the  numbered  domains  of  a  process, 
thereby  generating  a  protected  subsystem  instance.  The  supervisor 
maintains  for  each  process  a  table  of  associations  of  domain  numbers  and 
protected  subsystem  tree  names.  This  domain  table  can  also  record  the 
name  of  the  user  associated  with  the  process.  When  a  process  is  first 
created,  the  domain  table  might  appear  as  illustrated  in  "i.gure  4-3. 
Domain  0  is  occupied  by  an  instance  of  the  supervisor  .-rotected  sub¬ 
system  and  domain  1  is  occupied  by  the  home  protected  subsystem  instance 
for  the  user.  (A  directory  hierarchy  similar  to  that  shown  in  Figure 
4-2  is  assumed.) 

When  a  procedure  executing  in  some  domain  of  a  process  calls  a 
gate  entry  point  into  the  file  system,  the  requested  operation  is  vali¬ 
dated  by  comparing  the  protected  subsystem  name  associated  with  the  re- 
querting  domain  and  the  user  name  associated  with  the  process  against 
the  appropriate  ACL.  The  mode  in  the  first  matching  ACL  element  deter¬ 
mines  if  the  request  will  be  performed.  If  no  ACL  element  matches, 
then  the  request  is  not  performed. 


Permission  Flags  for  Segments 


To  understand  how  a  pr>tected  subsystem  can  become  associated  with 


a  domain  of  a  process,  it  is  necessary  to  investigate  in  more  detail  the 
use  of  the  modes  which  may  be  specified  in  an  element  of  an  ACL  for  a 
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segment.  As  indicated  earlier,  these  modes  may  specify  read,  write, 
execute,  and  gate  permission.  When  a  procedure  executing  in  some  domain 
explicitly  or  implicitly  requests  of  the  file  system  that  a  segment  be 
made  accessible  from  that  domain,  the  matching  ACL  element  determines 
which  permission  bits  in  the  corresponding  descriptor  segment  entry 
(DSE)  will  be  set  on.  For  example,  if  the  segment  is  or  was  previously 
assigned  segment  number  £  in  the  virtual  memory  of  the  process,  if  the  re 
quest  is  from  domain  n,  and  if  the  permission  flags  in  the  matching  ACL 
element  indicate  read  and  execute  access,  then  DSEs.Rn  and  DSEs.En  are 
set  on  by  the  supervisor,  and  DSEs^Wn  and  DSEs.Gn  are  set  off. 

The  case  when  the  matching  ACL  entry  indicates  gate  permission  is 
a  little  more  complex.  Continuing  with  the  previous  example,  in  this 
case  only  DSEs.Gn  is  set  on  by  the  supervisor.  However,  DSEjj.GATES  and 
DSEj». DOMAIN  must  also  be  filled  in.  Recall  that  these  fields  indicate 
the  number  of  gate  entry  points  in  the  segment  and  the  number  of  the 
domain  for  which  they  are  gates,  respectively.  As  the  information 
source  for  these  fields,  two  new  attributes  for  a  segment  are  introduced. 
The  first  attribute,  which  may  or  may  not  apply  to  a  given  segment, 
says:  "this  segment  is  a  gate  into  protected  subsystem  <protected 
subsystem  tree  name>",  and  is  called  the  gate  attribute.  The  second 
attribute,  which  is  only  meaningful  when  the  first  is  applied,  says: 
"there  are  m  gate  entry  points  in  this  segment".  How  these  attritubes 
are  used  is  obvious.  If  gate  permission  applies,  then  the  supervisor 
determines  if  the  protected  subsystem  named  by  the  gate  attribute  is 
already  associated  with  some  domain  of  the  process.  If  so,  then  the 
corresponding  domain  number  derived  from  the  domain  tabl^.  for  the 


process  is  used  to  set  DSE^.  DOMAIN.  If  not,  then  that  protected  sub¬ 
system  is  assigned  an  unoccupied  domain  of  the  process,  and  the  number 
of  this  domain  is  used  to  set  DSE^. DOMAIN.  DSE£. GATES  is  set  directly 
from  the  second  attribute.  Thus,  a  protected  subsystem  is  associated 
with  a  domain  of  a  process  when  the  first  attempt  is  made  to  get  at  a 
segment  containing  gates  into  that  protected  subsystem. 

If  all  eight  of  the  domains  of  a  process  are  occupied  at  the  time 
when  a  new  protected  subsystem  is  to  be  associated  with  the  process. 


a 

a 

5S 


I 


-I 

I 

3 


1 

I 

I 

« 

A 

S3 

Sj 

I 

J 


then  it  is  necessary  to  free  an  occupied  domain  to  make  room.  The 
choice  of  which  domain  to  free,  i.e.,  which  protected  subsystem  instance 
to  remove  from  the  process,  is  best  made  by  the  user  associated  with  the 
process  or  a  program  provided  by  him.  With  the  reasonable  restriction 
that  the  domain  to  be  freed  have  no  outstanding  invocations,  the  desig¬ 
nated  domain  is  easily  freed  by  turning  off  all  the  permission  bits  in 
the  corresponding  column  of  the  descriptor  segment,  turning  off  all 
gate  permission  bits  in  other  columns  that  correspond  to  gates  into  the 
freed  domain,  and  appropriately  updating  various  supervisor  data  bases. 
The  execution  environment  of  the  freed  domain  must  also  be  returned  to 
the  unused  state.  Reusing  domains  is  much  easier  than  reusing  DSE's. 

The  reason  is  that  segment  numbers  diffuse  into  non-supervisor-controlled 
data  segments  as  part  of  stored  pointers,  making  it  vevy  difficult  to 
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locate  all  instances  of  pointers  referring  to  the  segment  previously 
associated  with  a  reused  DSE.  Domain  numbers  are  not  part  of  stored 
pointers,  however,  and  appear  only  in  supervisor-controlled  data  segments. 
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Controlling  the  Gate  Attribute 


In  general,  given  that  a  particular  protected  subsystem  instance 
has  permission  to  modify  the  ACL  of  an  object  at  all,  there  need  be  no 
finer  control  on  the  particular  modification.  Any  element  may  be  deleted 
from  the  ACL  and  any  element  may  be  added.  There  need  be  no  constraint 
on  the  protected  subsystem  instance  named  or  the  mode  specified  in  an 
added  element.  (To  keep  things  consistent  the  supervisor  might  enforce 
the  rule  that  the  specification  of  gate  permission  in  an  ACL  element 
for  a  segment  can  be  made  only  if  the  gate  attribute  is  present  for  the 
segment.)  The  ability  to  set  the  gate  attribute  for  a  segment,  however, 
needs  to  be  carefully  controlled.  Jn  particular,  if  a  procedure  execut¬ 
ing  in  a  protected  subsystem  instance  which  has  proper  permission  to 
change  the  attributes  of  some  segment  could  specify  a  gate  attribute 
for  that  segment  naming  an  arbitrary  protected  subsystem,  then  no  pro¬ 
tected  subsystem  would  be  secure.  Any  user  could  create,  say  from  his 
home  protected  subsystem  instance,  a  gate  into  any  other  protected  sub¬ 
system  and  thereby  cause  a  procedure  he  constructed  to  execute  in  any 
other  prji.c«.ted  subsystem.  The  ability  to  create  gates  into  a  protected 
subsystem  needs  to  be  restricted  to  those  responsible  for  the  protected 
subsystem  (or  their  designates).  The  ACL  on  a  protected  subsystem  pro¬ 
vides  this  control. 

There  need  be  only  one  kind  c*  permission  flag  that  can  appear  in 
an  ACL  element  of  a  protected  subsystem:  the  "define  gates"  permission 
flag.  In  order  for  some  protected  subsvstera  instance  to  set  tiie  gate 
attribute  for  some  segment  to  specify  that  the.  segment  contains  gates 
into  a  protected  subsystem  with  tree  name  T,  a  matching  element  on  the 
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ACL  of  T  must  give  the  requesting  protected  subsystem  instance  “define 
gates"  permission.  Thus,  in  addition  to  providing  a  tree  name  for  a 
protected  subsystem,  a  protected  subsystem  object  in  the  directory 
hierarchy  controls  the  creation  of  gates  into  the  protected  subsystem. 

Examples  of.  Access  Control  Lists 

A  few  examples  will  help  to  sharpen  the  meaning  and  use  of  ACL's 
on  protected  subsystems  and  segments.  To  start  with,  imagine  that  each 
system  user  ha3  a  two-part  projeet/persor.  name,  that  a  home  directory 
with  the  tree  name  "root>projects>PROJECT_NAME>PERSON_NAME"  is  provided 
for  each  user,  and  that  a  home  protected  subsystem  with  the  name 
"root>projects>PROJECT_NAME>PERSON_NAM£>home"  is  provided  for  each  user. 
Only  the  home  protected  subsystem  instance  of  the  user  and  the  home  pro¬ 
tected  subsystem  instance  of  his  project  administrator  have  permission 

l 

to  perform  operations  on  the  user's  home  directory,  including  modifying 
the  ACL's  c£  directly  inferior  segments,  directories,  and  protected 
subsys  terns . 

The  most  frequently  used  ACL  elements  by  a  user  will  be  those 
giving  access  to  his  home  protected  sub.  ystera  instance.  Following  the 
assumptions  just  outlined,  such.  ACL  elements  tor  the  user  "CompSys. Jones’ 
would  be  expressed  as: 

rcot>projects>CompSys> Jones>home: CompSys. Jones  <jmode> 

This  specification  will  he  ro  frequently  used  (even  in  the  examples  in 
this  section)  and  is  so  awkward  that  a  shorthand  notation  is  adopted  to 
express  the  home  protected  subsystem  instance  of  a  user.  It  is  juse 
the  user's  name  preceeded  by  a  colon.  Thus  the  ACL  element: 
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: CompSys .Jones  <mode> 

is  equivalent  to  the  previous  expression.*  A  data  segment  that  this 
user  creates  for  his  own  use,  then,  would  bear  the  ACL  element: 

: CompS ys .Jones  read,  write 

while  a  procedure  segment  created  for  his  own  use  would  bear  the  ACL 
element: 

:CompSys .Jones  read,  execute 

This  procedure  segment  could  he  shared  with  his  friend  "Smith"  in  the 
same  project  by  adding  to  its  ACL  the  element: 

: CompS ys .Smith  read,  execute 

Nov;  imagine  that  user  "CompSys .Jones"  wishes  to  create  a  protected 
subsystem  that  encapsulates  one  procedure  segment  containing  gate  entry 
points  and  one  data  segment.  He  will  name  this  protected  subsystem 
"ex_ps"  and  put  it  in  his  home  directory.  Thus,  its  tree  name  is 
"root>projects>CompSys>Jones>ex_ps".  The  aCI.-  of  this  protected  subsys¬ 
tem  is  set  with  the  single  entry: 

: CompSys .Jones  define  gates 

which  gives  user  "CompSys .Jones"  permission  to  define  gates  for  the  pro¬ 
tected  subsystem  when  executing  in  his  home  protected  subsystem  instance 
The  procedure  segment,  is  then  given  a  gate  attribute  for  the  protected 
subsystem  "roo^projects^ompSys^onss^ez-^ps".  Initially,  the  ACL  of 
the  procedure  segment  has  two  elements.  They  are: 


In  a  real  implementation  conventions  also  would  be  required  to  shorten 
the  expression  of  other  commonly  used  protected  subsystem  instances  in 
ACL  elements.  No  further  conventions  will  be  introduced  here,  however. 


Suppose  now  that  user  "CompSys .Smith"  wants  to  borrow  this  protected 
subsystem.  User  "CompSys .Jones"  can  permit  this  by  adding  the  element: 

:CompSys .Smith  gate 

to  the  ACL  of  the  procedure  segment  containing  gates  into  the  protected 
subsystem.  This  gives  user  "CompSys .Smith"  permission  to  call  these 
gate  entry  points  from  his  home  protected  subsystem  instance  and  estab¬ 


lish  an  instance  of  the  protected  subsystem  "ex_ps"  in  his  process. 

This  simple  example  illustrates  the  general  pattern  for  defining 
and  controlling  the  sharing  of  u  protected  subsystem.  All  the  procedure 
and  data  segments  of  the  protected  subsystem  are  made  directly  accessible 
in  appropriate  ways  from  any  instance  of  the  subsystem.  The  sharing 
of  the  protected  subsystem  is  then  controlled  by  giving  other  protected 


The  pattern  for  controlling  the  sharing  of  protected  subsystems 
allows  the  access  of  one  protected  subsystem  instance  to  another  t^  be 
revoked  in  a  particularly  smooth  way  by  removing  the  ACL  entries  giving 
the  former  gate  access  to  the  gate  segments  of  the  latter.  If  the 
latter  happens  to  be  executing  at  the  time  this  gate  access  is  revoked, 
execution  is  not  stopped  instantaneously.  Rather,  execution  continues 
until  the  cross-domain  return  terminates  the  activities  of  the  protected 
subsystem  instance  in  an  orderly  fashion.  Thus,  the  protected  subsystem 
instance  is  not  stopped  executing  at  an  awkward  moment  leaving  component 
data  bases  in  an  inconsistent  state.  Because  of  the  revoked  gate  access, 
however,  further  cross-domain  calls  back  into  the  protected  subsystem 
instance  by  the  former  will  not  be  allowed. 


Other  Issues 

The  decision  to  provide  general  support  for  user-defined  protected 
subsystems  in  a  computer  utility  impacts  other  areas  of  the  software 
system  besides  the  file  system.  One  of  the  most  important  is  the  execu¬ 
tion  environment  provided  by  the  system  for  procedures.  A  procedure 
segment  that  can  be  used  as  a  building  block  is  of  necessity  pure  and 
may  contain  ambiguous  unresolved  references  to  other  procedure  and  data 
segments.  In  order  to  execute,  the  procedure  segment  must  be  provided 
with  an  impure  appendage  in  which  to  store  linkage  information  and 
static  variables,  a  stack  segment  in  which  to  allocate  activation  records, 
and  information  seen  as  search  rules  [4]  with  which  to  resolve  the 
ambiguous  references  to  other  procedure  and  data  segments.  It  is 
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essential  that  all  these  aspects  of  the  execution  environment  which 
can  affect  the  operation  of  a  procedure  be  provided  by  the  system  on  a 
per  domain  basis,  and  that  a  standard  initial  execution  environment  be 
defined  which  is  guaranteed  by  the  supervisor  to  exist  in  any  domain 
of  a  process.  Thus,  when  a  protected  subsystem  instance  is  associated 
with  a  domain  of  some  process,  the  procedures  of  thaL  protected  sub¬ 
system  can  know  what  execution  environment  will  be  provided  initially 
and  therefore  can  be  constructed  to  operate  correctly  in  that 
environment. 

Multics  already  meets  this  requirement.  I/O  stream  name  defini¬ 
tions  and  attachments,  reference  name  definitions,  and  search  rule 
definitions  are  limited  in  scope  to  a  single  domain  of  a  process  and 
always  given  a  system-defined  initial  state.  A  stack  segment  and  a 
segment  for  linkage  information  are  provided  for  each  domain  of  a  pro¬ 
cess  and  are  given  system-defined  initial  states. 

Other  system  functions  which  affect  the  secure  operation  of  a 
multidomain  computation  include  error  detection  and  handling  (for 
example,  the  PL/I  condition  mechanisms),  process  interruption  via  the 
attention  key  of  the  user's  terminal,  input/output,  and  accounting. 

The  mechanisms  in  Multics  for  performing  these  and  other  functions, 
with  minor  revisions,  appear  to  be  adequate  for  supporting  multidomain 
computations. 

Finally,  in  order  for  the  procedures  of  a  protected  subsystem  to 
make  meaningful  decisions  on  whether  or  not  to  fulfill  requests  received 
in  the  form  of  cross-domain  calls,  it  must  be  possible  for  these  proce¬ 
dures  to  determine  the  identity  oi  the  protected  subsystem  instance 
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making  the  request.  For  this  purpose  a  supervisor  gate  should  be 
provided  which  allows  a  procedure  executing  in  some  domain  to  determine 
the  tree  name  of  the  protected  subsystem  instance  from  which  the  last 
incoming  cross-domain  call  was  made.  It  may  be  appropriate  to  provide 
a  supervisor  gate  which  essentially  makes  the  contents  of  the  domain 
table  of  a  process  available  to  procedures  executing  in  any  domain  of 
a  process. 


Summary 

This  chapter  has  presented  a  brief  description  of  a  software  second 
layer  for  the  processor  protection  mechanisms  described  in  Chapters  2 
and  3.  The  purpose  of  this  material  is  to  demonstrate  one  way  to  har¬ 
ness  the  processor  protection  mechanisms  so  that  users  can  define  and 
control  the  sharing  of  protected  subsystems.  There  are  many  degrees  of 
freedom  in  constructing  a  software  system  to  harness  the  hardware  pro¬ 
tection  mechanisms.  Further  research  may  produce  a  software  system 
organization  that  provides  a  more  simple,  natural,  and  flexible  user 
interface  for  controlling  sharing  in  a  computer  utility  than  the  inter¬ 


face  developed  in  this  chapter.  The  software  system  outlined  here. 


however,  demonstrates  that  a  practical  protection  facility  meeting  the 
objectives  presented  in  Chapter  1  can  be  constructed  based  on  the  hard¬ 
ware  protection  mechanisms  developed  in  this  thesis. 


CHAPTER  5 
CONCLUSIONS 

This  thesis  has  described  protection  mechanisms  for  a  computer 
utility  which,  in  addition  to  allowing  controlled  sharing  of  programs 
and  data  among  users,  allow  controlled  sharing  of  user-defined  protected 
subsystems.  These  mechanisms  are  practical  to  implement  using  the  hard¬ 
ware  and  software  technology  available  today,  and  if  implemented  would 
provide  a  practical  and  sophisticated  facility  for  controlling  infor¬ 
mation  sharing  in  an  operational  computer  utility. 

The  unique  aspect  of  these  protection  mechanisms  is  the  efficient, 
natural,  and  general  manner  in  which  they  support  the  controlled  sharing 
of  user-defined  protected  subsystems.  A  protected  subsystem  is  a  col¬ 
lection  of  programs  and  data  bases  encapsulated  so  that  other  executing 
programs  can  invoke  certain  component  programs  within  the  protected  sub¬ 
system,  but  are  prevented  from  reading  or  writing  component  programs  and 
data  bases,  and  are  prevented  from  disrupting  che  intended  -operation  of 
the  component  programs.  The  ability  to  define  and  share  protected  sub¬ 
systems  provides  users  with  a  flexible  and  powerful  means  for  controlling 
access  to  stored  information.  By  defining  appropriate  protected  subsys¬ 
tems,  for  example,  users  can  implement  complex  controls  on  access  to  data 

bases,  share  proprietary  algorithms  without  divulging  the  structure  of 

* 

the  algorithms,  or  limit  the  damage  that  borrowed  programs  can  do  to  the 
programs  and  data  bases  of  the  borrower. 
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In  the  first  example,  by  encapsulating  various  data  bases  in  a  pro¬ 
tected  subsystem  with  programs  that  he  provides,  a  user  can  force  all 
references  to  the  data  bases  attempted  by  programs  outside  the  protected 
subsystem  to  be  made  by  invoking  these  caretaker  programs.  The  user  can 
specify  arbitrarily  complex  controls  on  access  to  the  encapsulated  data 
bases  since  he  writes  the  programs  that  judge,  perform,  and  record  re¬ 
quested  references.  Providing  users  with  the  ability  to  write  programs 
for  controlling  access  to  data  bases  has  an  important  impact  on  the 
structure  of  the  computer  utility.  It  means  that  the  system  need  not 
provide  protection  mechanisms  that  directly  implement  complex,  content- 
dependent  controls  on  access  to  stored  information.  Rather,  the  system 
only  need  implement  the  general  mechanisms  required  for  users  to  define 
the  encapsulation  of  programs  and  data  bases  in  protected  subsystems  and 
for  users  to  control  the  sharing  of  protected  subsystems.  More  complex 
controls  on  access  to  stored  information  than  are  directly  provided  by 
the  system  can  be  implemented  by  the  users  themselves  by  encapsulating 
caretaker  programs  with  data  bases  in  protected  subsystems.  The  result 
is  that  arbitrarily  complex  control  on  access  to  stored  programs  and 
data  can  be  implemented  based  on  a  general,  fixed,  fairly  simple  set  of 
system-provided  protection  mechanisms. 

The  second  example  use  for  protected  subsystems,  sharing  proprietary 
algorithms  without  divulging  the  structure  of  the  algorithms,  takes  ad¬ 
vantage  of  the  fact  that  programs  in  a  protected  subsystem  may  be  invoked 
by  outside  programs  but  not  read  by  them.  In  addition,  none  of  the  tem¬ 
porary  or  permanent  data  associated  with  the  programs  in  the  protected 
subsystem  may  be  read  or  written  by  outside  progiams.  Thus,  the  programs 


in  a  protected  subsystem  may  be  used  by  other  programs,  bu*-  no  aspect  of 


their  structure  examined. 


The  third  example  use  for  protected  subsystems,  limiting  the  damage 


that  borrowed  programs  can  do  to  the  programs  and  data  of  the  borrower. 


is  based  on  the  fact  that  programs  inside  a  protected  subsystem  can  in¬ 


voke  programs  outside  without  compromising  the  protected  subsystem. 


Thus,  a  borrower  only  need  arrange  that  his  programs  and  data  form  a 


protected  subsystem  and  that  a  borrowed  program  not  be  nart  of  that  pro¬ 


tected  subsystem.  Then,  if  by  malice  or  error  the  borrowed  program  be¬ 


haves  in  an  unexpected  way,  it  will  not  be  able  to  damage  the  programs 


and  dara  of  the  borrower. 


protection  mechanisms  described  in  this  thesis  for  supporting 


user-  .ned  protected  subsystems  allow  multiple,  independent  protected 


subsy  to  be  combined  in  a  single  computation  without  compromising 


the  prc  >n  of  the  individual  subsystems.  The  mechanisms  are  based 


on  the  division  of  a  computation  into  independent  domains  of  access  priv¬ 


ilege,  each  of  which  may  encapsulate  a  protected  subsystem.  The  central 


component  of  these  mechanisms  is  a  hardware  processor  that  fully  supports 


a  multidomain  computation  impleme!  ted  as  a  single  process  whose  address 


space  is  a  segmented  virtual  memory.  This  processor  allows  a  standard 


interprocedure  call  with  arguments  to  change  the  domain  of  execution  of 


the  process.  All  the  semantic  implications  of  an  interprocedure  call 


as  defined  in  a  high-level  programming  language  like  PL/I  are  accomodated 


on  a  cross-domain  call  without  compromising  the  protection  of  th.  sub¬ 


systems  encapsulated  by  either  of  the  domains  involved.  The  processor 


design  represents  the  first  time  that  hardware  mechanisms  for  fully 
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automating  cross-domain  calls  between  independent  domains  of  a  compu¬ 
tation  have  been  described. 

The  processor  rscogniz' s  and  enforces  two  kinds  of  access  capabil¬ 
ities:  static  and  dynamic.  Static  access  capabilities  represent  the 
encapsulation  of  segments  of  procedure  and  data  in  protected  subsystems 
and  control  the  ability  of  procedures  executing  in  one  protected  sub¬ 
system  to  invoke  procedures  of  another  via  a  cross-domain  call.  Dynamic 
access  capabilities  correspond  to  the  arguments  of  cross-domain  calls. 
The  processor  automatically  adds  to  the  called  domain  dynamic  access 
capabilities  to  reference  whatever  arguments  accompany  a  cross-domain 
call  and  automatically  removes  these  capabilities  whenever  the  subse¬ 
quent  return  occurs.  The  distinction  between  static  and  dynamic  access 
capabilities  corresponds  to  an  apparently  fundamental  division  of  the 
access  privilege  associated  with  a  process  that  executes  in  a  multi- 
domain  environment  into  the  capabilities  associated  with  the  address 
space  component  of  the  process  (a  segmented  virtual  memory  in  this  case) 
and  the  capabilities  associated  with  the  execution  point  component  of 
the  process. 

The  processor  is  the  key  to  both  the  efficiency  and  the  naturalness 
of  the  protection  mechanisms.  Because  the  processor  automatically  vali¬ 
dates  each  reference  made  by  an  executing  program  against  the  static  or 
dynamic  access  capabilities  in  the  domain  of  execution  and  automatically 
performs  cross-domain  calls,  little  intervention  by  supervisor  software 
is  required  for  the  enforcement  of  the  access  constraints  associated 
with  a  multidomain  computation  as  that  computation  executes.  Because 
on  a  cross-domain  call  the  processor  is  able  to  interpret  the  standard 
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argument  list  and  create  in  the  called  domain  dynamic  access  capabilities 
that  exactly  correspond  to  the  arguments,  the  user  has  the  natural  inter¬ 
face  to  the  cross-domain  call  mechanism  of  the  call  and  return  statements 
in  a  high-level  programming  language. 

In  addition  to  the  hardware  processor,  supporting  software  was  dis¬ 
cussed.  This  software,  when  used  in  conjunction  with  the  hardware  pro¬ 
tection  mechanisms,  provides  an  environment  in  which  users  of  the  com¬ 
puter  utility  can  construct  and  share  procedure  segments,  data  segments, 
and  protected  subsystems.  This  protection  facility  extends  the  idea 
inherent  in  programming  generality  of  using  programs  as  building  blocks 
to  allow  protected  subsystems  to  be  used  as  building  blocks  as  well. 
Independently  written  and  compiled  procedure  segments  may  be  combined 
in  different  ways  along  with  the  associated  data  segments  to  form  pro¬ 
tected  subsystems  without  recompiling  the  procedure  segments.  Independ¬ 
ently  defined  protected  subsystems  may  be  combined  in  different  ways  as 
cooperative  partners  in  various  computations  without  either  modifying 
the  protected  subsystems  or  altering  the  component  procedure  segments. 

The  ease  with  which  procedure  segments,  data  segments,  and  protected  sub¬ 
systems  provided  by  different  users  can  be  combined  to  perform  different 
computations  will  encourage  the  users  of  the  computer  utility  to  commun¬ 
icate,  cooperate,  ana  build  upon  one  another's  work. 

Taken  together,  the  hardware  and  software  mechanisms  described  in 
this  thesis  constitute  an  existence  proof  of  the  feasibility  of  building 
protection  mechanisms  for  a  computer  utility  that  allow  multiple  user- 
defined  protected  subsystems,  mutually  suspicious  of  one  another,  to 
cooperate  in  a  single  computation  in  an  efficient  and  natural  way. 
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Areas  for  Further  Research 

The  topic  of  protection  mechanisms  for  computer  systems  is  by  no 
means  exhausted  as  a  viable  research  topic.  In  this  final  section  of 
the  thesis  two  of  the  many  areas  for  further  research  are  discussed 
briefly.  The  first  is  the  user  interface  for  controlling  sharing  in  a 
computer  utility.  As  indicated  in  Chapter  4,  further  research  may  pro¬ 
duce  a  software  system  organization  that  provides  a  more  simple,  flex¬ 
ible,  and  natural  user  interface  for  controlling  sharing  in  a  computer 
utility  than  that  described  in  this  thesis.  Making  the  user  interface 
as  simple  and  natural  as  possible  without  sacrificing  needed  flexibility 
is  very  important.  Experience  with  Multics  suggests  that  users  not 
accustomed  to  dealing  with  sophisticated  protection  mechanisms  frequent¬ 
ly  make  errors  when  specifying  to  the  system  the  access  to  be  allowed  to 
some  object.  Even  after  some  skill  is  developed  in  applying  the  protec¬ 
tion  mechanisms,  users  find  it  hard  to  be  sure  that  specifications  given 
to  the  system  to  control  the  access  to  some  object  result  in  the  intended 
pattern  of  access  being  allowed.  For  example,  it  is  very  hard  to  detect 
the  accidental  granting  of  too  much  access  to  some  object,  because  no 
obvious  errors  result  from  too  much  access  being  granted.  When  dealing 
with  user-defined  protected  subsystems  the  problem  probably  becomes 
worse,  for  access  specifications  become  embedded  in  programs  that  users 
construct . 

To  make  more  progress  on  this  important  problem  of  human  engineering, 
it  may  be  necessary  to  employ  an  actual  system  with  a  creative  user 
community  as  a  tool.  Only  by  applying  a  set  of  protection  mechanisms  to 
the  protection  needs  of  real  users  can  it  be  seen  where  user  mistakes 


commonly  are  made,  and  can  it  be  seen  what  aspects  of  the  flexibility 


provided  are  really  needed  and  what  aspects  complicate  the  mechanisms 


with  unneeded  flexibility.  It  would  be  feasible  to  construct  a  proto¬ 


type  of  the  system  proposed  in  this  thesis  to  use  as  such  a  tool.  Be¬ 


cause  of  the  close  relationship  of  che  overall  architecture  of  the  pro¬ 


cessor  described  here  to  the  architecture  of  the  new  Mullics  processor. 


only  a  few  of  the  major  functional  modules  of  that  processor  would  have 


to  be  altered  to  produce  a  processor  that  implements  most  of  the  protec¬ 


tion  mechanisms  described  in  Chapter  3.  Only  a  few  changes  are  required 


to  the  existing  Multics  software  to  produce  Lhe  software  system  described 


in  Chapter  4.  In  addition  to  testing  user  reaction  to  the  protection 


facilities  provided,  this  prototype  system  would  provide  an  environment 


in  which  to  test  improved  interfaces  and  to  develop  tools  that  allow 


users  to  debug  the  access  specifications  embodied  in  protected  subsys¬ 


tems  or  given  to  the  system-provided  protection  mechanisms. 


The  second  area  for  further  research  is  that  of  certification. 


Certification  means  guaranteeing  that  the  protection  mechanisms  in  a 


system  actually  implement  the  intended  protection  facility,  i.e.,  that 


no  mistakes  were  made  during  the  design  or  construction  of  system  pro¬ 


tection.  mechanisms  that  allow  these  mecl.anir  to  be  circumvented.  The 


essential  problem  is  that  there  exist  no  methodical  techniques  for  de¬ 


signing  or  constructing  systems  so  that  this  guarantee  can  be  made.  In 


addition,  the  protection  mechanisms  devised  to  date,  especially  their 


software  components,  are  much  too  complex  to  certify  by  inspection  once 


Hi 


constructed . 
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Protection  hardware  for  supporting  multidomain  computations,  such 
as  that  described  in  this  thesis,  offers  s~me  help  in  attacking  the  prob¬ 
lem  of  certifying  the  software  components  of  the  protection  mechanisms 
in  a  system.  The  hardware  can  ba  applied  tc  isolate  by  encapsulation  in 
protected  subsystems  those  software  components  that  are  critical  to  the 
correct  function  of  the  protection  mechanisms.  The  key  to  success,  and 
the  area  where  further  research  is  required,  is  making  small  and  simple 
those  software  components  which,  if  improperly  designed  or  implemented, 
or  if  violated,  would  compromise  the  protection  mechanisms  of  the  system. 
Once  made  small  and  simple,  and  their  correct  operation  certified,  the 
hardware  can  provide  enforced  isolation  for  these  components,  thus  insu¬ 
lating  them  from  errors  introduced  into  the  system  by  modifying  other, 
less  critical  components  of  the  software. 

The  two  areas  for  further  research  mentioned  above  are  only  a  small 
sample  of  the  work  that  remains  to  be  done  on  the  topic  of  protection 
mechanisms  for  computer  systems.  One  of  the  basic  problems  to  be  over¬ 
come  is  that  there  exists  such  a  lack  of  formal  knowledge  on  the  topic 
that  it  is  difficult  to  see  the  problems  that  remain  unsolved.  As  com¬ 
puter  systems  play  larger  and  more  important  roles  in  society,  protection 
mechanisms  will  become  increasingly  important  as  the  guardians  of  priva¬ 
cy.  The  design  and  implementa* ion  of  protection  mechanisms  must  become 
so  well  understood  ar.d  methodical  that,  as  a  matter  of  course,  commerical- 
ly  available  computer-based  information  systems  contain  protection  mecha¬ 
nisms  which  prevent  unauthorized  access  to  the  information  stored  in  them 
while  at  the  same  time  make  it  easy  for  users  to  communicate  when  appropri 
ate  by  sharing  information.  We  have  a  long  way  to  go  to  reach  this  goal. 
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